feat: Support multiple ethflow contracts

[sunce86]

Problem

To switch to the newly deployed Ethflow contract, the backend must support indexing and working with multiple Ethflow contracts simultaneously.

Updating the Ethflow contract address in the configuration isn't viable because many integrators are still using the old contract and will require time to transition.

Supporting multiple Ethflow contracts faces two main hurdles:

EventUpdater Design Limitation

EventUpdater, the core component responsible for event indexing and storing, is designed to handle only one contract.
Modifying EventUpdater to support multiple contracts would be highly complex and risk introducing bugs across other indexers.

Shared Database Schema

Ethflow events from all contracts are stored in the same database tables. Without differentiation, it becomes impossible to determine which data corresponds to which contract.

Suggested solution

Add a New Field for Contract Differentiation

Introduce a field, ethflow_contract_address, to all database tables storing Ethflow event data.
This field will allow differentiation of data for different contracts without requiring separate tables for each contract.

Adjust Data Handling Functions

Modify all functions responsible for reading and storing Ethflow events to account for the ethflow_contract_address field.
Since ethflow_contract_address is part of the metadata for every event, storing it in the database should be straightforward and will not require changes to the EventStoring trait signatures.

[sunce86]

Another idea worth exploring is to check whether EventRetrieving::get_events function can work with multiple addresses.

Theoretically this should be possible since implementations of this trait function usually use eth_getLogs under the hood. If possible, this would allow atomically inserting the events from both contracts into db and we could avoid adding ethflow_contract_address.

[anxolin]

is it easier if we just run 2 instances for the time of the transition?