Hook indexing learns about new messages as they are indexed about hyperlane-monorepo

[tkporter]

Relevant: https://github.com/hyperlane-xyz/issues/issues/977

[daniel-savu]

• when you index a message, send over a channel to the IGP task, an indication that IGP may have occurred in the same tx.
  • to get this event from a tx hash, can query for the tx receipt - generalizes well across EEs and no need to impl for sealevel (we do sequence based there)
• nice to have: also send a notification to the merkle tree indexer task to read the insertion

[tkporter]

Some thoughts on rolling out as it was mentioned yesterday we should have an explicit path toward seeing if this is effective -

Imo we already have decent metrics to be able to determine the success of this.

Because of low confidence in IGP indexing, atm we've whitelisted all known warp routes to not enforce IGP payments in the relayer (because we know that in order to send a message, they'll have paid the IGP):

• hyperlane context https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/typescript/infra/config/environments/mainnet3/agent.ts#L139-L156
• neutron context https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/typescript/infra/config/environments/mainnet3/agent.ts#L271-L278

As part of rolling this out, we should remove all these configurations except for the Neutron-origin ones (see https://github.com/hyperlane-xyz/issues/issues/1257, maybe Injective is affected too?) so that we start enforcing gas payments on EVM chains. If we see unprocessable messages from EVM origins for known metric app contexts, then we know something is up.

We could maybe go further and add a metric to count IGP payments indexed via this new method for metric app contexts, but imo this is overkill. As long as logs make it clear when an IGP payment is indexed via this new method and we have the above metrics / alerts to know if we find ourselves still having IGP indexing issues with known metric app contexts, imo we're fine