forkchoiceUpdate support

[tersec]

https://github.com/ethereum/execution-apis/blob/v1.0.0-alpha.5/src/engine/specification.md#engine_forkchoiceupdatedv1

Part of the merge.

[github-actions]

Unit Test Results

     12 files  ±0     759 suites  ±0   33m 45s ⏱️ - 3m 18s
1 535 tests ±0  1 489 ✔️ ±0  46 💤 ±0  0 ❌ ±0 
9 126 runs  ±0  9 030 ✔️ ±0  96 💤 ±0  0 ❌ ±0 

Results for commit 259dbef. ± Comparison against base commit 0f44d2e.

♻️ This comment has been updated with latest results.

[arnetheduck]

where do we handle exceptions for these calls?

[tersec]

In their callers, e.g.

nimbus-eth2/beacon_chain/gossip_processing/block_processor.nim

Lines 272 to 291 in 6893c63

	executionPayloadStatus =
	if hasExecutionPayload and
	# Allow local testnets to run without requiring an execution layer
	blck.blck.mergeData.message.body.execution_payload !=
	default(merge.ExecutionPayload):
	try:
	awaitWithTimeout(
	newExecutionPayload(
	self.consensusManager.web3Provider,
	blck.blck.mergeData.message.body.execution_payload),
	web3Timeout):
	info "runQueueProcessingLoop: newExecutionPayload timed out"
	"SYNCING"
	except CatchableError as err:
	info "runQueueProcessingLoop: newExecutionPayload failed",
	err = err.msg
	"SYNCING"
	else:
	# Vacuously
	"VALID"

I've found it useful to be able to decide how to interpret error conditions at a relatively outer layer of processing, rather than hide them in the raw RPC calling functions, because then one can treat a timeout, or certain errors, say, as equivalent to SYNCING, while others might be INVALID. This kind of policy isn't always consistent across callers (e.g., fcU has two callers: the block processor one can fail or time out, and it's mostly fine, but the validator duties one cannot) to bake into the lower-level functions.

[arnetheduck]

hm, we should probably condense those errors to an enum that represents the meaningful / actionable options in the "outer" layers

[tersec]

There's a distinction here to be made, but (potentially distinct sets of) enums might be appropriate for both:

1. the "VALID" / "SYNCING" / "INVALID" possibilities, specified by the engine API specification. This is defined in nim-web3. There was some issue with these, so in the interest of expediency, I reverted that field to a string. But one blocker for me in merging more of the kintsugi branch is figuring out what happened there, and properly using an enum again. This, however, shouldn't be adorned beyond what the specification prescribes, but rather mirror it.

2. Separately, there's a set of states that amounts to a superset of (1), plus some possible error conditions either contacting the EL or that the EL might return in addition to or instead of "VALID" / "SYNCING" / "INVALID". If one wants to move timeout, exception, and other error handling into the inner functions, these would need to be characterized.