feat: add debug_executePayload RPC to capture arbitrary execution witnesses

[meyer9]

This PR adds a new RPC endpoint:

debug_executePayload(parentBlockHash: BlockHash, payloadAttributes: PayloadAttributes, transactions: Vec<Bytes>) -> ExecutionWitness

This endpoint allows executing arbitrary transactions on top of parent block hash and returns the necessary state keys and trie preimages to verify the execution with only a state root.

To allow executing partial blocks, if a transaction fails, the storage loads and stores will still result in witnesses being included to be able to prove that the execution failed.

Return Value

{
  "keys": { ... },
  "state": { ... },
  "codes": { ... },
}

Currently, I have it returning the same data as debug_executionWitness, but I think we'll also want to include transaction results (receipts, which transactions failed/succeeded, etc).

I'm not sure what the interface should look like for the transaction results, but we could go with something like this to keep things simple:

{
  "result": {
    "state": "success",
    "receipts": [...],
    "successfulTransactions": ["tx1"],
    "failedTransactions": [],
  },
  "witness": {
    "keys": { ... },
    "state": { ... },
    "codes": { ... },
  }
}

Let me know if adding a transaction result makes sense and what

Open Questions

• Should we add a flag allowFailure: boolean that enables the behavior of not failing when a transaction fails?
• Should we include transaction status in the output? (See Return Value section)

Update 10/31 2:50 PT: Added payload attributes field after clarifying with Optimism team.

[clabby]

Similar to the first draft of the debug_executionWitness endpoint, we do need a bit more here. This endpoint also needs to apply the system transactions (4788) and OP Stack system transactions (Canyon's create2 deployer call, etc.)

Curious the Ithaca team's take here. Originally we didn't want to add this directly into the RPC endpoint implementation because of the duplication. For this we need to be able to access the payload building codepath, which may be a bit more annoying to get into the debug API.

[clabby]

A pretty key thing about this endpoint is that it can return witnesses in blocks that fail to entirely execute. With Holocene, there's the following case:

1. Block $A$ is sent to the engine, has a user-space tx that has an invalid signature.
2. Engine rejects block $A$
3. Rollup node trims off user-space transactions, sends deposit-only payload back to the engine (block $A\prime$).
4. Engine accepts block $A\prime$.

It looks like we're currently ignoring the errors during transaction processing (and short-circuiting if the block fails to fully execute), though will also need to return whether the payload could be cleanly applied on top of the state at the block requested for the consumer.

[meyer9]

Waiting on some new block builder improvements before adding this RPC endpoint. This will allow us to execute system transactions before other transactions in a block.