Revertible in-memory store

[rnbguy]

Closes #159

Supports revertibility in in-memory store directly, without RevertibleStore wrapper.

---

Revert in RevertibleStore

The old RevertibleStore relies on maintaining a list of processed operations - write and delete. If it has to revert on a failed transaction, it tries to revert the previous operations.

• if it was overwrite, overwrite with the old value
• if it was delete, insert the old value
• if it was insert, delete the current value

Problem

But this creates a problem with a deterministic Merkle root hash. overwrite-ing doesn't change the Merkle tree - but insert and delete may reorganize the Merkle tree. And we don't want to reorganize a Merkle tree on a failed transaction. That is, storage should have zero effect on a failed transaction.

Also, we don't have deletion support until #141 is merged. This is why we have this non-termination bug present #129.

Revert in new InMemoryStore

The new InMemoryStore has two copies of the current working store. These two copies are staged and pending.

Each transaction works on pending copy. When a transaction returns,

• If it succeeds, the store applies the transaction changes by copying pending to staged.
• If it fails, the store reverts the transaction changes by copying staged to pending.

When a block is committed, the staged copy is copied into the record of all committed stores.

Problem

This is not production-friendly. After each transaction, a whole store is copied from pending to staged or staged to pending.

[seanchen1991]

Once we address the len method, I think this is good to go 👍

[seanchen1991]

I like the expanded description of the problem you added to the PR description. I think the section on InMemoryStore should be added to the type's docstring.