State manager API changes

[mattdean-digicatapult]

This is to inform discussion of #268 as requested in that thread, but is not intended to be merged in it's current state.

[coveralls]

Coverage increased (+0.2%) to 85.945% when pulling 0711147 on mattdean-digicatapult:stateManagerCleanup-hacks into 4ecae8a on ethereumjs:master.

[holgerd77]

Oh, the state tests are actually passing on this? That’s already impressive, cool!

[mattdean-digicatapult]

I think all the necessary tests should be passing, with the cache tests being commented out as the exception. Honestly I had to make my changes that way in order to make sure what I was doing was even viable. Not sure what's going on with the Travis build, but I'm pretty sure my changes aren't at fault

[axic]

Sorry for that but since #266 was merged, this needs to be rebased.

[mattdean-digicatapult]

Thanks @axic, I've rebased and everything still seems to work. A few of the changes from #266 seemed to conflict in direct opposition to my changes, notably in the moving of the blockchain instance onto stateManager from the vm. I've stuck with my way for reasons discussed in #268, but I think it would be good to work out where the blockchain should sit so that we're not trampling on each others changes.

[axic]

I think to speed up the process of merging this we need to split it into smaller chunks. I can see one good first step is prefixing the soon-to-be-private variables with underscore (_cache, _trie) in a separate PR.

[mattdean-digicatapult]

Unquestionably this needs splitting up before it can be merged. My intention with this PR was really just to facilitate the discussion in #268. If others are happy with the logic I presented there I'm more than happy to start breaking this up into separate PRs.

[holgerd77]

Hi @mattdean-digicatapult, have sent you a message on Gitter which is time-critical, hijacking this thread to notify you on a second communcation means! 😄

[mattdean-digicatapult]

These changes have all now been merged to master. Closing