Engine API: engine_forkchoiceUpdated refinement

[mkalinin]

Refines engine_forkchoiceUpdated spec as per feedback by @MariusVanDerWijden:

• Adds and utilizes ForkchoiceState structure to be able to envelop the fork choice information in one argument. Proposed change regroups the parameter set of this method in a way that it has two subsets, forkchoiceState and payloadAttributes. Maintaining the parameter set of this method within two subsets does make sense since the semantics of forkchoiceUpdated method is twofold, and there is a parameter subset per each part of the semantics that can be updated independently.
• Adds payloadId to the response. It is natural if EL is responsible for the computation of build process identifiers as the process is initiated by EL. It also gets rid of the complexity related to maintaining the exact algorithm of the computation in the spec which involves versioning and collision resistance.

UPD re: payloadId type DATA vs QUANTITY. QUANTITY is semantically more strict than plain DATA hence this updated keeps the type of the payloadId field as DATA to avoid any additional restrictions caused by the semantics of the field type. One may argue that the length should rather be 32 Bytes then.

TODO

• The corresponding update in the consensus specs, Add payload id as a return value to notify_forkchoice_updated consensus-specs#2711

cc @lightclient @djrtwo @protolambda

[protolambda]

Nice changes, the API will be easier to implement with grouping of params and the return of an 8 byte payload ID.

This also alleviates my concerns (even if far fetched) of previous 8 byte payload IDs, as it's the EL, not the CL, that determines what to use.

[lightclient]

Returning payloadId will certainly make the interaction simpler.

[djrtwo]

excellent! a couple of minor nits