all: stateless witness builder and (self-)cross validator

[jwasinger]

This PR does the witness construction during block execution, after which a custom self-stateless-cross-validation step is added (if the entire thing is enabled via a CLI). No external validator is defined yet, the purpose of the current integration is to run consensus tests with witnesses and run live benchmarkers with witnesses to sanity check any possible faults. Metrics and benchmarks will probably need a followup PR to focus on that.

[jwasinger]

This adds a new test suite TestStatelessBlockchain which adds a large amount of running time to CI. We may consider disabling it as a last step before merging this when it is approved.

[jwasinger]

Converted back to draft while I address remaining TODOs (parts of the code are confusing rn).

[jwasinger]

@karalabe this still fails 2 tests:

go test -run=StatelessBlockchain -timeout=20m
--- FAIL: TestStatelessBlockchain (0.34s)
    --- FAIL: TestStatelessBlockchain/InvalidBlocks/bcUncleHeaderValidity/gasLimitTooLowExactBound.json (0.01s)
        --- FAIL: TestStatelessBlockchain/InvalidBlocks/bcUncleHeaderValidity/gasLimitTooLowExactBound.json/gasLimitTooLowExactBound_Cancun (0.00s)
--- FAIL: TestStatelessBlockchain (0.51s)
    --- FAIL: TestStatelessBlockchain/InvalidBlocks/bcUncleHeaderValidity/gasLimitTooLowExactBound2.json (0.01s)
        --- FAIL: TestStatelessBlockchain/InvalidBlocks/bcUncleHeaderValidity/gasLimitTooLowExactBound2.json/gasLimitTooLowExactBound2_Cancun (0.00s)
panic: runtime error: index out of range [0] with length 0 [recovered]
	panic: runtime error: index out of range [0] with length 0

I need to fix those and double-check and clean up the diff (parts are still a bit messy). Overall, I think it's getting close though.

[karalabe]

@jwasinger @rjl493456442 @fjl @holiman PTAL, the PR is ready for review/merge.

[karalabe]

FWIW, I'd appreciate a merge commit vs. squash merge to retain ownership of my massive cleanup commit.

[karalabe]

One thing I want to change. Replace the pre-root hash with the parent header. In the current shape of the code the pre-root is trusted, which allows the block being verified to be malicious (i.e. unverified pre-root == unverified starting state == arbitrary post state). By adding the parent header we are proving the link between the validated block and the pre-root state (via the parent header).

[rjl493456442]

SGTM, just a few nits

[karalabe]

There are some wonkyness left in, but I have a followup PR which does the live integration and that does further cleanups. Better to have the witness stuff in here and then have the mushing into our live codebase separately. Also a lot of stuff gets deleted that will not be needed any more with a live hook.

[immense055]

d86b650