Engine API: Refine message ordering. Take 2

[mkalinin]

Removes Message ordering mechanism based on request IDs. JSON-RPC request IDs might be difficult to get parsed depending on the JSON-RPC library. The new proposal doesn't rely on request IDs at all and removes the logic that is required to reset this ID, which in its turn introduces inconvenience for setups with multiple EL clients behind a load balancer.

The proposed approach doesn't require CL client software to send forkchoiceUpdated calls in a lock-step fashion. But it's based on the assumption that the underlying protocol doesn't mess up with the order of messages, i.e. if CL sends the following sequence of calls: [fcU(A), fcU(B)] then EL client will always receive fcU(A) before fcU(B). This assumption gets broken if HTTP over multiple TCP sessions is used as the underlying communication protocol.

[ajsutton]

This makes sense to me. Personally I think a CL would be incredibly brave to depend on http pipelining to preserve this order and probably should ensure it only has one in-flight message at a time, but if you control your underlying http library carefully enough it is possible to use pipelining so makes sense for the spec to allow it.

[djrtwo]

reasonable approach. keep it simple!

[lightclient]

LGTM