Engine API: add engine_exchangeTransitionConfigurationV1

[mkalinin]

Proposal

Proposes to add engine_exchangeTransitionConfigurationV1 method

Motivation

• Allows for EL heartbeat and for verifying that EL client distribution is configured correctly
• Gives ability for CL to ping EL constantly, match received configuration with its own and surface a problem to a user if misconfiguration occurs

This proposal introduces a method that is useful only before the merge transition with intention to deprecate it in a subsequent upgrade. Low implementation complexity should mitigate this downside.

[djrtwo]

Looks good! One minor question/suggestion

[djrtwo]

The alternative is that it's more of a ping/pong where each send their configuration. Thus both can see a mismatch and both can surface an error.

Do you think this would help reduce chance of user failures by both logs having the error?

[ryanschneider]

+1 to this idea, basically params is the CL's configuration and response is the EL's, and both sides SHOULD log a warning if the other configuration doesn't match.

[mkalinin]

I like this idea! 👍 I think we may re-use the same data structure. When TERMINAL_BLOCK_HASH is set CL client will send terminalBlockNumber: 0 as a block number is not a part of CL's configuration.

[mkalinin]

Although, what if it's called not by CL but by a script that checks every EL client in a cluster and then matches values with what are expected to be? Do we want to design for this use case? If yes, then we should make the parameter optional.

[djrtwo]

A cluster/advanced test could also add the config as a param. I think it's not worth the complxity of making this optional

[mkalinin]

I've updated the method to engine_exchangeTransitionConfigurationV1 with transitionConfiguration in params. Also, added "SHOULD surface an error..." for both CL and EL clients.

cc @ryanschneider @djrtwo

[ryanschneider]

lgtm!