feat: Retrieve finalized blocks from Ethereum

[bvrooman]

Related issues:

• Closes TOB-FUEL-43: Relayer should check for finalized blocks instead of block confirmations #1336

This PR changes the approach a Fuel node uses to determine the finalized blocks on the Ethereum blockchain.

The existing approach:

• Assume a "finalization period" - a period of time after which we assume a block is finalized. Generally, we assume a block is finalized after 100 new blocks have been produced afterwards
• Observe what the current block height is as reported by the Ethereum client
• Subtract the finalization period from the current height to get an assumed finalized block, i.e. current block height - 100

The problem with this approach, as outlined by Trail of Bits, is that finality cannot be guaranteed simply by the amount of time passed alone.

This PR proposes a more robust approach:

• Use the Ethereum client to query for the most recently finalized block directly. This is done using the Finalized tag in the query. See add safe and finalized tag to BlockNumber gakonst/ethers-rs#1792

This approach removes any assumption on our side as to what the finalized block is, and gets the canonically accepted finalized block from Ethereum.

[Voxelot]

Does removing the use of an inclusive range affect the correctness of doing a saturating_add here? It seems like there's a potential that local could be higher than remote in this case.

[bvrooman]

I do not believe that this changes the correctness. Prior to these changes, EthSyncGap used a single inclusive range to store its start and end values (local and remote respectively); with these changes, EthSyncGap stores its start and end values separately, and implements a conversion into an inclusive range where any range behaviour needs to be maintained. In effect, the correctness will be maintained.

At the point of instantiation, where we calculate the inputs to the EthSyncGap constructor, local remains unchanged, and remote is now the value returned by the Ethereum client. Before and after these changes, there is no guarantee that local is less than or equal to remote. This means that the EthSyncGap can be "empty", i.e., local is greater than or equal to remote. (An inclusive range allows the start to be greater than the end, in which case it is empty.)

In fact, some tests check the behaviour when local is greater than remote to ensure that no sync is necessary:

fuel-core/crates/services/relayer/src/service/state/test.rs

Line 30 in ec6a612

} => None; "ahead so doesn't need to sync"

[xgreenx]

I guess we can remove eth_blockNumber now

[bvrooman]

Yep, that's true. If we need it again in the future for whatever reason, we can add it back.