Validation endpoint prototype

[ckoopmann]

This is a very rough prototype that should implement at least some of the validation logic we are looking for.

On a high level I:
Added a new rpc endpoint / method validation_validateBuilderSubmissionV1 that acceps an execution payload as its only parameter, passes it into this validation method and returns the result.

Hoops I had to jump through to implement this:

1. General boilerplate to add a new rpc endpoint
2. I had to create a new ExecutionPayloadValidation struct and add a conversion method to the built in engine::payload::ExecutionPayload struct, because of differences in formatting. (camel vs snake case and hex vs. decimal numbers)

Testing:

I was able to verify that the block hash is correctly verified as well as some aspects of the withdrawals array.
However I have not yet been able to fully test the happy case. The closest I have come was when sending one of the example payloads to the synced node in which case it fails when checking the withdrawal index

To run the node with the new rpc endpoint do:
RUST_LOG=info reth node --full --metrics 127.0.0.1:9001 --http --http.api eth,validation,web3

Afterwards you should be able to test the rpc endpoint with:
curl --location '0.0.0.0:8545/' --header 'Content-Type: application/json' --data @rpc_message.json

With the rpc_message.json payload looking something like:

{
  "jsonrpc": "2.0",
  "method": "validation_validateBuilderSubmissionV1",
  "id": 1,
  "params": [
    {
      "parent_hash": "0x089dad69074a0f8096625853cebb35f893e71a4dcaa41b235867b07ae4e54dc2",
      "fee_recipient": "0x6d2e03b7EfFEae98BD302A9F836D0d6Ab0002766",
      ...<REMAINING_FIELDS_OF_EXECUTION_PAYLOAD>
     }
     ]
}

Open Questions / Issues:

1. Unlike the existing endpoint this validation method only uses the ExecutionPayload and ignores the "Message" and "Signature". Probably have to extend the logic to also verify the signature. (if that is part of the expected behaviour).
2. Are there any other validation steps that we currently do that are not included in here yet ? (haven't really compared the implementation details of the full_validation method here with the reference implementation here).
3. The API is probably a bit different. Here I added a new json-rpc method. As far as I understand the existing builder is a REST api ?
4. How can we do some proper testing for this ? (including succesfull validation of valid payloads)

[ckoopmann]

Replaced by:
ultrasoundmoney/reth-payload-validator#1