Observe multiple contracts for ETH flow

[sunce86]

Description

Implements the idea explained here: #3248 (comment)

The Ethflow contract of interest: https://etherscan.io/address/0x40a50cf069e992aa4536211b23f286ef88752187#code (probably useful to better review and understand refunder code changes)

This solution has a limitation: we can't specify a block number to start indexing the new contract. Upon autopilot restart, indexing resumes from the latest block recorded in the database. This approach assumes synchronized and atomic insertion of events for both the old and new contracts.
As a result, new contract events will only be indexed from the point when the new contract address is added to the autopilot configuration.

This is acceptable under the following assumptions:

• The configuration to read from the new contract is applied first.
• The new contract is officially published, and orders are created afterward.

Changes

• EthFlowRefundRetriever and CoWSwapOnchainOrdersContract are now observing multiple ethflow contracts at the same time.
• Refunder service adjusted to also detect the ethflow contract for which the refund should be done (so far this was irrelevant since there was only one contract)
• Updated E2E test for refunder.

How to test

Existing e2e tests.
Updated refunder e2e test to simulate two orders being created on two different ethflow contracts and being properly refunded.
I also manually verified (through observing logs on e2e tests) that indexing from multiple contracts works properly.

[MartinquaXD]

Approach looks like it should work but I think the code in the refunder could be simplified quite a lot.

[MartinquaXD]

The refunder uses our auto batching logic under the hood. If make use of this this function would probably end up being a lot easier to read.

[sunce86]

Not sure what are you referring to exactly.

[MartinquaXD]

The underlying HttpTransport automatically batches individual RPC calls together. So instead of manually calling .batch_call() you can simple do things like join_all(rpc_calls) and it will do the same thing while being a lot easier to read.

[MartinquaXD]

Given that an OrderUid can only belong to a single contract we can ditch the vector. And I would suggest to simply copy the contract type instead of messing around with the address to make the code easier to read. The refunder is doing barely any work anyway so I think we should optimize for readability over performance here.

Suggested change

	) -> Vec<(OrderUid, Vec<CoWSwapEthFlowAddress>)> {
	) -> Vec<(OrderUid, CoWSwapEthFlow)> {

[sunce86]

Using contract instead of address is not convenient since PartialEq and Hash are not implemented for CoWSwapEthFlow

[squadgazzz]

LGTM, assuming all the comments above will be addressed.

[MartinquaXD]

Pushed some changes directly:

• turned 1 error log into warn because it will become a very noisy alert when we consider the transition period over but people still submit orders via the old contract
• also logged the UID in ☝️
• avoided clunky batch call logic and relied on autobatching of underlying HttpTransport
• grouped ethflow orders in first function instead of second to streamline things
• use Vec::truncate() instead of .into_iter().take(n).collect()

[sunce86]

LG.

[fedgiac]

I went quickly through the code and the changes look reasonable to me, everything is consistent with my understanding of the contract and the refunder.