Check which beacons of a beacon set need to be updated

[Siegrift]

See the slack thread and a bit older thread.

The old Airseeker implementation always attempts to update all beacons and uses tryMulticall to avoid issues with some updates reverting. This could be prevented by checking which beacons can be updated and updating only those.

Specifically, we could:

1. Get all on chain values of the data feed beacons
2. Filter beacons for which we have more up to date signed data (these could be updated)
3. Check whether updating beacons above would trigger the beacon set update (reuse on-chain value for non-updated beacons)
4. Do not use dummy data multicall estimation (there is no reason for multi call to revert apart from RPC provider failure).
5. Maybe not use the fixed 2_000_000 gas limit in case multicall estimation fails?
6. Use multicall instead of tryMulticall to do dAPI updates

[bbenligiray]

Anyone can use the signed API to update an individual Beacon so not using tryMulticall() is a bad idea. The issue with omitting individual Beacon updates (while using tryMulticall()) is similar, it provides more freedom to third parties to execute specific combinations of updates. A redundant Beacon update is still useful in disabling all signed data coming before it. Arguably this is still optional as it's not bulletproof.

[bbenligiray]

I misunderstood, this is about Beacon updates that are guaranteed to revert (barring a block reorg). This is safe to do but we should still use tryMulticall().

[Siegrift]

Agreed on call to do first check which beacon updates will revert and omit those. The implementation should even omit the beacon set update (as well as beacon updates) if it detects that the beacon set doesn't need to be updated.

We should still continue using tryMulticall because people can attack us by taking the signed data from mempool and doing a beacon update with higher gas price making their transaction be included before ours and making our multicall revert.

The spec should also be updated.