This PR shows an experimental approach to in-stream snapshotting. The following aspects should be noted about the approach used:

• intentionally surfaces snapshot as an event to
  • minimise surprises; if a developer regularly traverses the snapshotting schemas and log, it's more likely to be borne in mind
  • allow the snapshotting correctness to be subjected to normal testing
• only ever writes a snapshot-event when one or more other events are being written
  • Maintaining multiple snapshot versions becomes expensive (both in terms of storage and in terms of having to traverse them when doing actual material work)
  • Readers doing fixup writes is liable to trigger concurrency conflicts

Basic technique:

• reads backward in batches
  • if a snapshot is encountered, the read process is stopped as we can now fold from the compaction event forward
  • if we hit the start of the stream, we deem ourselves not to have encountered a snapshot
• when writing
  • the need for a snapshot (based on whether we're within a single page and/or there's a compaction event falling within the last page given the current state) is surfaced as an IsCompactionDue predicate in the Context
  • the command processing flow actively checks this and generates the Snapshot event in an explicit fashion

Work

• Define commands / tests
• Minimize reads
• Ensure we have tests for batch capacities
• Log compaction savings