feat(relayer): two-step bridge + watchdog + full merkle proof

[cyberhorsey]

1. Update the relayer indexer subcommand to be able to index either MessageSent or MessageReceived, add the event name to the queue name to have separate queues for each flow. We will now deploy two relayer indexers for each source-dest chain, to feed either queue (to be either Processed, or checked if they need to be Suspended).

2. Update the relayer processor to be able to handle the the new two-step bridge, as well as full merkle proofs: if a proofReceipt exists onchain, we are in the second step, if it doesnt, we are in the first step. The processor needs to be able to wait after sending the "MessageReceive" call if we are in the first step, and wait to finalize it. Ifi t is in the "MessageExecuted" step, the relayer can return early and acknowledge the queue message.

If a relayer exits early after processing a call in the first step, the message needs to be unacknowledged and go back onto the queue, to repeat the process, except detect it now has a ProofReceipt and can be processed without a proof.

3. Add a new watchdog subcommand, which reads from the new MessageReceived queue, and calls isMessageSent on the source bridge. If it exists, acknowledge the queue message succesfully. If it doesn't exist, we need to transact suspend message on chain for this transaction, and add that to the database for querying via a UI.

4. Add a new migration, repository, interface, implementation, and route to the relayer API subcommand for:
   GET /suspendedTransactions - list all suspended transactions in a paginated response.

5. increment a Prometheus counter when we suspend, so we can use this for an alert to alert David and I.

6. Update proof changes with latest signal service/bridge code.

TODO:

• Through the UI, we probably want a way to be able to suspend an individual transaction. However, we need to be careful about how we do this - most likely the safest way is simple through the frontend using a watchdog private key. If we want to have it in the backend, then we need a way to authenticate known persons who can suspend transactions.

Summary by CodeRabbit

• New Features
  • Added watchdog software for monitoring and processing messages between Ethereum chains.
  • Introduced suspended transactions handling and repository.
  • New event handling and subscription logic based on event names.
  • Enhanced message processing with proof retrieval methods.
  • Added functionality for encoding storage proofs.
  • New HTTP route for retrieving suspended transactions.
• Enhancements
  • Streamlined ABI definitions across ERC20, ERC721, and ERC1155 vaults.
  • Improved event definitions and added new fields in various structures for better data representation.
  • Updated server configurations to include suspended transactions repository.
  • Refined gas-related operations with new utility functions.
• Bug Fixes
  • Fixed message processing logic and error handling in various components.
• Documentation
  • Added SQL migration script documentation for creating suspended_transactions table.
• Refactor
  • Renamed and refactored methods and variables for clarity and consistency across the system.
• Tests
  • Introduced and updated test cases for new configurations, encoding methods, and gas operations.

[cyberhorsey]

FYI This is just waiting for some changes I've asked Ruby to do with regards to ERC20/721/1155s (now that we have a generic invocation method, the previous method of checking which type of token we have no longer works).

completed