Use smaller block number - from the contract and from the RPC

[Siegrift]

See thread.

There are some chains, for which the contract block number is slightly higher than the block number returned by the RPC. The problem is that when this happens, we fail to get nonce (and delay the update considerably).

We've agreed on the call to use the smaller of the block number from the contract and by the RPC. The RPC call is made after the contract call. There is a possibility of a race condition, but we will see if this turns out to be a problem in practice.

[bdrhn9]

We discussed this issue with @bbenligiray, and we've decided that using the block number from the RPC call is a more elegant approach for the following reasons:

• It helps resolve idiosyncrasies we've encountered on Arbitrum and Arbitrum-based chains.
• It aligns with the well-accepted practice of obtaining the block number directly from the RPC call.

Regarding the order of the static call to read the active data feed batch and eth_blockNumber, a decision was necessary. Fetching the block number first and then reading the active data feed batch can create a race condition, leading to a failure to submit updates due to an expired nonce. Conversely, reading the active data feed batch first and then fetching the block number can also cause a race condition, potentially resulting in redundant update transactions. To minimize the possibility of both types of race conditions, firing both calls simultaneously looks like more proper way.

[bbenligiray]

Ben pointed out that these are Arbitrum Orbit chains, i.e., Arbitrum-based L3s