Event log compaction

[bryannaegele]

This issue is to discuss event log growth currently being unbounded. In order prevent OOM errors, the event log must be rolled up with some regularity.

etcd's approach to this problem appears to be compacting based on a combination of max allowed entries and elapsed time - https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/maintenance.md#raft-log-retention. Each of these approaches seem desirable to cover most situations.

Initial thoughts on possible options would be:

1. snapshot at max_sequence_id and delete from there back
2. snapshot at x events back and delete from there back
3. delete back from the sequence id on the last snapshot

I propose we implement each of these approaches with sane defaults. Users can adjust these configuration options and pick a strategy that best suits their needs.

[NeilMenne]

To document a few things we discussed out of band, I do think that compaction is essential to the long term success of an event sourced application.

Your proposal for snapshotting periodically seems reasonable and fits into the GenServer approach that we have.

Deleting events should definitely be disabled by default, but having an operation that allows for it both in the store and more importantly on the aggregate is a good idea as well.

[NeilMenne]

Developing a solution for dealing with max_sequence_id or even warning when that's getting close is probably a separate concern since we're actually talking about the max for the integer type in postgres.