Piper/refactor api for access to state db

[pipermerriam]

replaces #611

What was wrong?

The original context manager API for dealing with the account_db was built to make sure that the state_root stayed updated.

I'm of the opinion that 1) we no longer need this mechanism and 2) that the readability overhead isn't worth it anymore.

How was it fixed?

Still a WIP but the plan is to take steps towards making State fully immutable. Things like apply_transaction and/or execute_transaction will return either state_root, computation or maybe state_diff, computation.

All of the other things like creation of the receipt will move upwards in the stack.

Cute Animal Picture

[pipermerriam]

@carver mind looking this over. The gas estimation tests are now returning different numbers (looks to be consistently off by 12 gas). First pass on my part didn't surface anything obvious. Hoping fresh eyes find something I didn't.

[pipermerriam]

Problems that remain or surfaced with this PR.

• It's still easy to forget to call account_db.persist().
  • Making the account_db ephemeral within the State object and using a context manager API for initializing the root checkpoint and persisting it should fix this.
  • Not exposing the AccountDB.state_root until AccountDB.persist() has been called might also work.
• The State object has block stuff in it.
  • This should all be moved up to the VM
• The State.gas_used can probably be removed.
• The State.state_root is awkward and should probably be removed (see above about making account_db ephemeral
• The VM.block property is problematic statefulness.
• The VM.pack_block method is awkward.

[pipermerriam]

This wasn't used anywhere and the new gas estimation API using the binary search seemed categorically superior so... removing this.

[carver]

Cool, good progress. Just one piece that I think is redundant.

[carver]

do_call() already does the snapshot/revert internally. Based on the name (and its presumed equivalence to rpc api's eth_call), it seems reasonable to expect do_call() to continue handling that. So I think this method's change can be undone.

[pipermerriam]

Also, we should be able to remove do_call if we get enough of the stateless/pure stuff done right. Just calling down into one of the deeper APIs which doesn't mutate and throwing away the state diff (or something like that).