simulators/ethereum/engine: Add ForkchoiceUpdated with Invalid Payload Attributes Test

[marioevz]

This PR adds test cases where a ForkchoiceUpdated directive is sent to the EL with invalid payload attributes, timestamp==0.

The expected behavior remains undecided with two options proposed, as per @mkalinin:

Option 1

0. Check headBlock is known and there is no missing data, if not respond with SYNCING
1. Check headBlock is VALID, if not respond with INVALID
2. Apply forkchoiceState
3. Check payloadAttributes, if invalid respond with error: code: Invalid payload attributes
4. Start payload build process and respond with VALID

Option 2

0. Check headBlock is known and there is no missing data, if not respond with SYNCING
1. Check payloadAttributes (requires a lookup to database to get a timestamp of yet to be applied headBlock), if invalid respond with error: code: Invalid payload attributes
2. Check headBlock is VALID, if not respond with INVALID
3. Start payload build process and respond with VALID

Currently in this test case Option 2 check is implemented but can be changed as necessary.

Current outcome per client:

• Geth: Error but forkchoice is applied
• Nethermind: Error and forkchoice is rolled back
• Erigon: No error on any timestamp value
• EthJS: No error on any timestamp value

cc @MariusVanDerWijden @MarekM25

[mkalinin]

Thanks a lot for making this scenario into tests! The spec work is pending. I need to think more about this case in terms of the spec, which option to go with. It's on the list and probably will be done this week

[MariusVanDerWijden]

I think Option 1 makes the most sense, we want to apply the fork choice even if we are unable to produce a payload (How that might happen is irrelevant imo).
And if we get payload params we should make sure that invalid timestamps produce an error imo

[mkalinin]

The corresponding PR to the spec ethereum/execution-apis#211

[marioevz]

I have updated to the test case to match the option in the updated spec.
Let me know if this is ok.