Use Fork variants instead of version for JsonPayload types

[macladson]

Issue Addressed

With Fulu, we increment the engine API version for get_payload but we do not also increment new_payload.
In Lighthouse, we have a tight coupling between these version numbers and the Fork variants.
For example, both get_payload_v3 and new_payload_v3 correspond to Deneb, v4 to Electra, etc.

However this coupling breaks with Fulu where only get_payload_v5 is related to Fulu and new_payload_v4 now also corresponds to Fulu (new_payload_v5 does not exist). While we can work around this, it creates a confusing situation where the versions and Fork variants are out of sync.

See the following code snippet where we are using the v4 endpoint, and yet passing a V5 payload variant:

lighthouse/beacon_node/execution_layer/src/engine_api/http.rs

Lines 849 to 870 in 522bd9e

	pub async fn new_payload_v4_fulu<E: EthSpec>(
	&self,
	new_payload_request_fulu: NewPayloadRequestFulu<'_, E>,
	) -> Result<PayloadStatusV1, Error> {
	let params = json!([
	JsonExecutionPayload::V5(new_payload_request_fulu.execution_payload.clone().into()),
	new_payload_request_fulu.versioned_hashes,
	new_payload_request_fulu.parent_beacon_block_root,
	new_payload_request_fulu
	.execution_requests
	.get_execution_requests_list(),
	]);
	let response: JsonPayloadStatusV1 = self
	.rpc_request(
	ENGINE_NEW_PAYLOAD_V4,
	params,
	ENGINE_NEW_PAYLOAD_TIMEOUT * self.execution_timeout_multiplier,
	)
	.await?;
	Ok(response.into())

Proposed Changes

1. Remove new_payload_v5 as it is unused in Fulu.
2. Rename the JsonExecutionPayload and JsonGetExecutionPayloadResponse types to use Fork variants instead of version variants. This clarifies the relationship between them.

Other Considerations

The engine API spec does refer to these types by version, however ExecutionPayloadV4 and above do not actually exist since ExecutionPayload hasn't changed since Deneb. If we value close adherence to spec naming, we could consider reverting back to the old versioned JsonPayload types by implementing: #7841. By doing this, the JsonExecutionPayload type would stop at V3 (Deneb). This is actually what is used in the spec

[michaelsproul]

LGTM, this is a good clarification.

I think this helps us out in the short-term while we get Gloas merged in, and then we can come back for removing the payload type duplication.

[ethDreamer]

Yeah let's just merge this and merge #7728 . The next thing i will probably do is rename everything in this file from Json* to Engine* since the entire reason these objects exist is because their json serialization on the engine_api is different from the beacon_api. But let's leave that for another PR.

[jimmygchen]

LGTM too!

[mergify]

This pull request has been removed from the queue for the following reason: checks failed.

The merge conditions cannot be satisfied due to failing checks:

• ☑️ test-suite-success

You can check the last failing draft PR here: #7920.

You may have to fix your CI before adding the pull request to the queue again.
If you update this pull request, to fix the CI, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio requeue comment.

[macladson]

@Mergifyio requeue

[mergify]

requeue

✅ The queue state of this pull request has been cleaned. It can be re-embarked automatically