Use an abstract VM trait for integration tests

[alexytsu]

WIP: Expect invocations not working anymore. Will need a way to abstract over expectations

#1236

Tracking branch of end-state. This will be broken up and reviewed in chunks:
#1285
#1288
#1289

[codecov-commenter]

Codecov Report

Merging #1265 (bf1e378) into alex/1236-abstract-vm-trait-easy-tests (15e29d3) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Additional details and impacted files

@@                           Coverage Diff                            @@
##           alex/1236-abstract-vm-trait-easy-tests    #1265    +/-   ##
========================================================================
  Coverage                                   90.64%   90.64%            
========================================================================
  Files                                         133      133            
  Lines                                       27019    26908   -111     
========================================================================
- Hits                                        24492    24392   -100     
+ Misses                                       2527     2516    -11     

Impacted Files	Coverage Δ
test_vm/src/lib.rs	80.98% <100.00%> (-1.43%)	⬇️
test_vm/src/util.rs	99.92% <100.00%> (+0.97%)	⬆️

... and 4 files with indirect coverage changes

[alexytsu]

@anorth this is a WIP but the entire util functionality has been refactored to work with the abstract VM.

I'm partway through refactoring the tests themselves to rely solely on the abstracted trait rather than methods on TestVM but am running into considerable friction around ExpectInvocation logic which seems to be quite central to some of the tests.

[anorth]

I reviewed about half of this, enough to generate a few requested changes.

It would be ok not to convert all the tests at once. E.g. where there are some new trait methods required for state hacking, we can just mark those tests for follow-up (and file an issue to finish them off), and get them in a new PR. In fact I'd perhaps prefer that this PR only addressed a few of the smaller tests while we settle on the patterns, making it easier to review, land, and then build upon.

I reckon that things like v.assert_state_invariants should be able to be extracted as helper functions, rather than methods. Then we can call them regardless of the VM in use. I think we should start off assuming that we do want those kind of checks to run all the time, though I could be convinced they're not wanted when using the real VM for some reason.

[anorth]

Thanks. We need to think about how to make this structure more ergonomic. Since the #[test] methods are mostly uniform boilerplate, perhaps we'll be able to make a macro #[vmtest] or similar that automates that little wrapper function. But we also need to think about moving the test bodies out to be importable elsewhere.

[alexytsu]

Outstanding items are tracked in #1294