Atomically persist blocks, headers, & tries

[carver]

What was wrong?

We can end up with inconsistent state when shutting down trinity (say, a header persisted, but the canonical head not updated, or missing the transaction or uncle data, etc). This is because we persist all database writes immediately.

How was it fixed?

Persist batches of writes atomically.

This used to be one massive pull, which were peeled off into:

• AtomicDB #1295
• Require BaseAtomicDB in ChainDB and HeaderDB #1296
• Switch to explicit atomic_batch() database handle #1304

Now this PR just does final step: it uses the new db.atomic_batch() API to force all writes to atomically succeed (or fail) in three places:

• persisting a block
• persisting a trie data dict
• persisting a chain of headers

There are probably other places that would benefit from doing an atomic batch (both for performance and correctness reasons), but these were the lowest hanging fruit.

This introduced several shadow methods in the chain and header dbs, that accept a BaseDB as an argument, so we can pass in the atomic batch for writing. They were moved to classmethod so that no one accidentally adds a reference to self.db going forward.

Cute Animal Picture

[carver]

I decided it's better to just do this the right way, and get real levelDB transaction atomic commits. So this is still a WIP.

[carver]

Wrapping up for the day. Last thing I'd want to do is detect and blow up if the batch_write() context was entered twice (unless leveldb supports it, in which case, I might try to add support into BatchableDB)

[carver]

All of the prep work, and type changing is really just to support 13211f0 and 0f42713, which is relatively small, but a huge win IMO.

Edit: Argh, just saw the CI failures. Re-marking WIP :(

[carver]

This is a little big. I'll peel it off into parts, starting with #1295

[carver]

... and onto #1296

[carver]

and #1304 -- which fixes some conceptual issues that will slightly change the approach in this PR: it will require that header and chain db can write to an explicitly provided database handle, instead of their internal self.db, when desired.

[cburgdorf]

Looks good to me 👍 It's a shame that our benchmark suite still entirely relies on the MemoryDB which pretty much eliminates any chance to see the perf impact of this.