Epic: Add scraper support for Cosmos

[tkporter]

The scraper makes a few EVM-centric assumptions, but nothing excessive. You can think of the work as roughly: "change the scraper to not be EVM-centric, implement some Cosmos-specific code, make sure we can test this, and deploy"

In chronological order & each containing day estimates:

Note: sequencing-wise, it may make sense to coordinate with #4271 for many things including shipping this

Cosmos scraping

Preview Give feedback

1. Figure out rollout approach for Solana and Cosmos scraper work #4345
   agent alt-VM +2
   
2. Scraper: addresses in DB should always be 32 bytes #3330
   agent cosmos scraper +3
3. Scraper cosmos support: fully implement HyperlaneProvider for CosmosProvider #3332
   agent scraper +2
   
4. Implement Cosmos indexing of delivered messages #4300
   +0
   
5. Successfully scrape Cosmos chains in e2e test #3355
   CI cosmos scraper testing +4
   
6. Deploy scraper with Cosmos chains like Neutron / Injective in mainnet3 #3356
   cosmos scraper +2
   

based on research completed in https://github.com/hyperlane-xyz/issues/issues/903

Related: hyperlane-xyz/hyperlane-explorer#165

[tkporter]

A "scratch pad" for my thoughts as a dove in:

• Why does it need to use the forward message sync cursor instead of the forward backward? Feels like forward backward is better
• Why do we have so many rows in cursor?
  • seems like we insert a new one each time we update the watermark, why? why not just update?

select count(*) from cursor;
  count
---------
 9688274
(1 row)

• Why is cursor even required?

  • this is for the watermark cursor. It seems like we use the same watermark for IGP and delivery indexing, which isn't ideal

• We should probably change all insertions to be robust to conflicts so we can avoid situations like what we got into earlier around block hashes. See https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/rust/agents/scraper/src/db/message.rs#L226 as an example

Changes to schema required:

1. Our address type isn't 32 bytes. Should it be?

/// Addresses are to be stored as binary.
#[allow(non_upper_case_globals)]
pub const Address: ColumnType = ColumnType::Binary(BlobSize::Tiny);

Maybe this isn't so bad? But this feels awkward - would probably be easier to keep everything as 32 bytes. Worth considering the explorer situation.

We use address_to_bytes in various places to convert H256s like senders / recipients / mailbox addresses to a 20 bye representation, which is very EVM specific.

This is used:
a. message table: sender, recipient, and origin mailbox
b. delivered_message table: destination_mailbox

2. unsigned doesn't do what we want - we need a larger data type Postgres doesn't support unsigned integers, but scraper DB schema assumes it does #3121

3. transaction is very ethereum-specific:

 id  |        time_created        |                                hash                                | block_id | gas_limit | max_priority_fee_per_gas | max_fee_per_gas | gas_price  | effective_gas_price | nonce |                   sender                   |                 recipient                  | gas_used | cumulative_gas_used
-----+----------------------------+--------------------------------------------------------------------+----------+-----------+--------------------------+-----------------+------------+---------------------+-------+--------------------------------------------+--------------------------------------------+----------+---------------------
 299 | 2023-10-20 21:35:29.902644 | \xff8c550fd9d8311983af61ece61ba0983312e191e6fa0ea076540cc0749ea386 |      293 |    305335 |               1500000000 |      1500000100 | 1500000050 |          1500000050 |    76 | \xfad1c94469700833717fa8a3017278bc1ca8031c | \x086e902d2f99bcceaa28b31747ec6dc5fd43b1be |   250733 |              297586

We don't need cumulative_gas_used. The rest are probably ok to keep tbh