Engine API: define payload bodies requests

[mkalinin]

The steal of #218 (I hope @arnetheduck doesn't mind) as we need this change in Shanghai ASAP.

Differences from the original PR:

• withdrawals are added to ExecutionBlockBodyV1 struct
• engine_getPayloadBodiesByRangeV1 isn't optional and must be supported by all EL clients
• Request timeouts are set to 10s which is the RESP_TIMEOUT param value from the p2p-interface spec
• nil is replaced by null to follow JSON format

[arnetheduck]

lgtm, thanks for the rebase!

[mkalinin]

I am wondering how we can make these methods future compatible with ExecutionPayloadBodyV2 and other more advanced versions:

• either return null when V1 method faces blocks requiring V2 version
• or make V2 method V1 aware, i.e. mix V1 | V2 struct versions in the response

[lightclient]

Shouldn't this be determinable by the number of responses? Is there ever a case where there would be a gap? Right now, I expect every request over a boundary to be like:

->  engine_getPayloadBodiesByRangeV1(100, 5)
<- [block_101, block_102, null, null, null]

Basically I think the trailing nulls are redundant info.

[mkalinin]

Good point. @arnetheduck why would CL need trailing nulls?

[arnetheduck]

I don't think it matters greatly either way - we have to consider that a syncing client cannot reliably tell if it should be a null or not past its own head, so we can just pick one "style" and go with it.

Arguably, not sending "null" carries the "I don't know" distinction vs "I know there's nothing past that block" as happens with a historical request over a boundary where the EL "knows" there are blocks after the gap, so it might indeed be better to not include the null for any request past head.

[arnetheduck]

future compatible

I'm not convinced there's much to do on this front - ie a client that doesn't understand v2 will not be able to do anything (significantly) better - ie maybe show an informational log to the user that the fork that they're on no longer is supported by the connected EL.. a v2 client on the other hand will already know what to do.

[mkalinin]

I have added a requirement to set withdrawals to null if pre-Shanghai bodies are returned which explicitly makes the new structure backwards compatible.