eth_syncing response differs from Engine API response

[mark-terry]

Description

Teku reports that it is awaiting Besu sync, but Besu responds with false when eth_syncing is called. The responses from eth_syncing and the Engine APIs report different statuses.

It should be investigated whether these responses can be made more consistent.

Related ticket: #4436

Acceptance Criteria

eth_syncing returns a response consistent with Teku's reporting of Besu's sync status.

Versions (Add all that apply)

• Software version: 22.7.5

[macfarla]

https://discord.com/channels/595666850260713488/804019759934078987/1026646251418157056

We've been using eth_syncing to detect when our node is behind so we can stop certain operations. But eth_syncing seems under-specified; the highestBlock might not be known to be valid, and syncing execution layers are importing blocks without knowing if they are valid. In a Github discussion (https://github.com/ethereum/go-ethereum/issues/25845#issuecomment-1259447646) @M H Swende (holiman) points out that an execution client doesn't have enough information to know whether it is actually behind anymore, and wants eth_syncing to refer to a subset of catching-up behaviors, distinguishing state sync from importing. I mostly want it to be the same API because of my own usage, but it would not be a problem for us if there was a separate eth_behind flag.

In the same vein, the execution layer seems to require some additional information from the consensus layer in order to be able to know whether it is behind. I think it can be accomplished by adding a block number to one of the ForkChoiceUpdated parameters. My preference would be for there to be a block number for each of head, safe, and finalized.

[iamhsk]

Potentially look at this after Shanghai upgrade