core/stateless, eth: add debug_executionWitnessByHash

[gballet]

This is a request by @kevaundray.

This PR adds a new system call, which re-executes a block with stateless mode activated, so that the witness data are collected and returned.

This has some differences with the reth equivalent (list will likely :

1. The returned block header is json-encoded and not rlp-encoded
2. nil codes aren't added
3. the keys field is present but is always empty - this is an agreement with Kev, that will be done in a later PR. The role of this PR is to find the disagreements with reth.

Note that, besides these issues, I still do find some differences with what reth returns, which is why this PR is in Draft mode.

[s1na]

I checked the difference in witness between geth and reth for block https://etherscan.io/block/23174550.
Find the results here: geth-witness-550-sorted.json
reth-witness-550-sorted.json

Apart from the differences noted above:

• codes field seems to have a minor difference:
  • First, reth produces a duplicate code in 0x363d3d373d3d363d7f360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc545af43d6000803e6038573d6000fd5b3d6000f3
  • Geth returns 2 less codes. One is 0x. The other is a big contract 0x6080604052600436106100745760003560e01c8063ad5c46481161004e.... It seems wasteful to include an empty code so I'd say that should be changed in reth. But why the second code is missing is an interesting question.

In addition, good to clarify these in the spec:

• Name of the method debug_executionWitness vs debug_executeWitnessByHash.
• We only take block hash as parameter, reth only takes block number. Both are weird imo we should take block num or hash or go for 2 methods.

[jsign]

We only take block hash as parameter, reth only takes block number. Both are weird imo we should take block num or hash or go for 2 methods.

@s1na, reg this, Reth has both.

[rjl493456442]

Does anyone know what Keys refers to?

[rjl493456442]

keys: this is a list of all the keys present in the state. It is particularly ordered first by address and then storage slot keys. e.g.,

<address1><address2><slot-1-address2><slot-2-address2><address3><sloat-1-address3>. etc.