vere: chunk event log into epochs

[mcevoypeter]

Split the event log into epochs, which will enable event log truncation.

The new directory hierarchy of the <pier>/.urb/log directory looks like:

dev/.urb/log
├── 0i1
│   ├── data.mdb
│   ├── lifecycle.bin
│   ├── lock.mdb
│   └── version.bin
├── 0i112
│   ├── data.mdb
│   ├── lock.mdb
│   ├── north.bin
│   ├── south.bin
│   └── version.bin
├── 0i201
│   ├── data.mdb
│   ├── lock.mdb
│   ├── north.bin
│   ├── south.bin
│   └── version.bin
├── fake.bin
└── who.bin

Each epoch contains a version.bin file specifying the epoch version it represents as well as an LMDB instance for storing the epoch's events. The first epoch 0i1, has lifecycle.bin, which specifies the length of the boot sequence. All non-first epochs have snapshots representing the state of the system immediately before the epoch's first event was applied (i.e. applying the snapshot in 0i112 is equivalent to replaying up to and including event 111).

Migration from the old event log format is in place so long as the incremental snapshot is up to date with the event log. If not, instructions for how to prepare for migration are printed to the console should migration fail. Rollover to a new epoch occurs immediately after migration.

Rollover to a new epoch is dictated by a fixed max event count for an epoch; when the max event count is reached, a new epoch is automatically created.

Key additions:

• epoc module: manages the persistence of an epoch behind a simple interface. The storage method is still LMDB, but nothing about the epoc interface leaks that information, and so it should be fairly easy to swap in a different database should the need arise.
• evlo module: manages the epochs that comprise the event log behind a simple interface and provides both synchronous and asynchronous commit options. Similar to the epoc interface, the evlo interface hides the existence of epochs from the users, which enables greater flexibility should the need to change the event log structure arise sometime in the future.

Key dependencies:

• list module: doubly-linked list abstraction.
• path module: file path abstraction.
• bile module: binary file abstraction.

Remaining loose ends:

• Address the nuances at the intersection of truncation and replaying the boot sequence. As things currently stand, the boot sequence must be replayed if the incremental snapshot is absent, which is clearly problematic if the first epoch, which contains the boot sequence has been dropped.
• Decide on an appropriate max event count for epochs.

Next steps:

• Decide on a truncation policy.

Testing:

• Migration:

$ urbit-1.8 -F dev
$ urbit-peter-epoch dev

• Replay:

$ rm dev/.urb/chk/*.bin
$ urbit-peter-epoch dev

• Rollover: occurs automatically after a fixed number of events. Checked with ls dev/.urb/log. Both replay and migration were tested when a single epoch (i.e. 0i1) was present and when multiple epochs (up to ten of them) were present.

[joemfb]

This is great! I'll come back with a more detailed review soon, but wanted to get these notes to you ASAP.

This PR removes some functionality (some of which was added/restored while your branch was in progress):

• lockfile management: in vere/disk.c (moved from vere/io/unix.c), now additionally used in worker/main.c. this is likely causing the CI issues
• commit batch size histogram: in vere/disk.c. it's fine to disable the printf on exit (I wasn't going to ship it), but we really want to capture this info,and at least be able to print it from a debugger. Eventually, it'll be wired into the %info system, accessible by a signal, &c.
• partial replay: I only just reimplemented this on jb/wip-urth. It's not much code, and should be straightforward to port here.

We'll need to refactor some of these mars.c changes. Separate functions for boot and replay are important, and we don't want to be using implementation-detail macros like try_epoch across module boundaries. Might be easiest for me to make a PR on top of yours for this sort of thing, but I wanted to mention it now.

Finally, the new module names also aren't going to fly. While we occasionally drift (lmdb, http), it's important to aim for meaningful, 4-letter english words. Some ideas:

• disk, rock (hard disk, stability, persistence)
• tale, saga, epic (story, history. grand heroic narrative, connects to epoch)
• anon (following one after another)
• fact, feat, know

[joemfb]

More info about CI failures:

[mcevoypeter]

A summary of the latest batch of commits that I pushed:

1. Address CI failures.
2. Change event log module name from evlo to saga.
3. Add support for partial replay.
4. Add support for truncation by only running the boot sequence when the first epoch is the only epoch present.

[mcevoypeter]

Bookmark: review of c3 changes complete.

[zalberico]

Unfortunately, the work this PR was built on top of (the mars/"urth" refactor) had a show stopping bug that required the underlying work in it to get broken down and shipped in pieces (I can't find any details about this bug anywhere in github - if there's a link please add it here).

As a result, this PR cannot ship as is and would need to be reimplemented on top of the current vere.

The underlying work this PR is built on that can be safely pulled out and shipped independently from the mars/urth refactor is being pulled out and shipped separately (memory corruption fixes, demand paging, other fixes in the 1.14rc).

Joe is working on a minimal command line version of event log truncation in the mean time which should help us be unblocked and we'll see if that's able to ship before he's out.

We'll take a look at this live implementation work in the new runtime repo once we have that doing releases.