feat(evm)!: support its v2 deployment

[milapsheth]

This PR adds ITS hub support. ITS hub is deployed from this commit. It's linked to the axelarnet-gateway contract which is registered under the chain name axelarnet.

An EVM ITS v2 pre-release contract (with ITS Hub support) is deployed to Amplifier EVM chains. The relayer also has support for processing ITS hub calls.

See the setup and test sections to try sending ITS calls.

Setup Repo

1. npm ci
2. See Test instructions towards the end

Deploy EVM ITS

To deploy your own ITS contracts on an EVM chain, run the following:

1. Checkout this branch in the ITS repo locally.
2. Run npm ci && npm run build && npm run test
3. Set PRIVATE_KEY=... and ENV=devnet-amplifier in .env
4. Update package.json in this repo to point to the local ITS path. For example: "@axelar-network/interchain-token-service": "file:../interchain-token-service",
5. Run npm install
6. Deploy ITS to your EVM chain via: node evm/deploy-its.js -s "v2.0.0rc2 devnet-amplifier" --proxySalt 'v2.0.0 devnet-amplifier' -m create2 -e devnet-amplifier -n [chain name]
7. Set the trusted address for ITS Hub:
   node evm/its.js -n [chain] --action setTrustedAddress --trustedChain axelar
8. Configure remote chains to route via ITS hub (run this for each remote chain you want to connect to):
   node evm/its.js -n [chain] --action setTrustedAddress --trustedChain [remote chain, e.g. avalanche-fuji, xrpl] --trustedAddress hub

Upgrade EVM ITS

1. Ensure you have re-built ITS contracts locally, and then run npm install again to point to the updated version.
2. Deploy ITS helper contracts with a new salt, while reusing the existing ITS proxy address
   node evm/deploy-its.js -s "v2.0.0rc3 devnet-amplifier" -m create2 -n [chain name] --reuseProxy
3. Upgrade ITS proxies to use the new implementation
   node evm/deploy-its.js -n [chain name] --upgrade

Verify EVM ITS on explorer (optional)

1. See the prerequisites here (specifically, creating a keys.json in this repo for your chain, and updating local ITS repo's hardhat.config.js).
2. Ensure that the devnet-amplifier.json config for the chain has the API listed, example:

      "explorer": {
        "name": "Opscan",
        "url": "https://sepolia-optimistic.etherscan.io",
        "api": "https://api-sepolia-optimistic.etherscan.io/api"
      },

5. Verify: node ./evm/verify-contract.js -c InterchainTokenService -d ../interchain-token-service/ -n [chain name]
6. An error is returned on failure. The verification could fail due to various reasons (explorer API rate limit, unsupported verification API, incorrect configs, incorrect repo build etc.)

Test

All registered ITS contracts on the ITS Hub can be queried via:
axelard q wasm contract-state smart axelar10jzzmv5m7da7dn2xsfac0yqe7zamy34uedx3e28laq0p6f3f8dzqp649fp '"all_its_addresses"' --node http://devnet-amplifier.axelar.dev:26657

Deploy Token

1. Deploy an Interchain token via the Factory. Change the salt to a unique salt (for each new deployment):
   node ./evm/interchainTokenFactory.js -n avalanche-fuji --action deployInterchainToken --name 'Test' --symbol 'TEST' --decimals 6 -s [salt] --initialSupply 10000
2. The tokenId of the deployed token is printed in the output
3. Deploy the same token to a remote chain (example GMP call). Use the same salt as the above when deploying the same token to remote chains:
   node ./evm/interchainTokenFactory.js -n avalanche-fuji --action deployRemoteInterchainToken -s [salt] --destinationChain optimism-sepolia
4. If the source chain is operated by Axelar, the relayer will automatically route this message to the destination ITS contract via ITS hub. Steps 5-9 are described for completeness if a relayer isn't active for the source or destination chain.
5. Get the payload from the contract call event on the source chain event
6. Execute the message at ITS hub via Axelarnet gateway (message id is the tx hash and event index within that tx's log). Example tx. Note that 0x shouldn't be added to the payload below:
   axelard tx wasm execute axelar1yvfcrdke7fasxfaxx2r706h7h85rnk3w68cc5f4fkmafz5j755ssl8h9p0 '{ "execute": { "cc_id": { "source_chain": "avalanche-fuji" , "message_id": "[message id]" }, "payload": "[hex encoded payload without leading 0x]" } }' --from amplifier --gas auto --gas-adjustment 1.2
7. The tx receipt shows a contract_called event with the message_id for the second GMP call, and the new payload
8. The relayer will submit the proof automatically to the gateway (for enabled EVM chains, example). If your chain is an external one, you can construct proof manually, and then submit it to the EVM gateway via:
   node evm/gateway.js -n [chain] --action submitProof --multisigSessionId [session id]
9. Execute destination ITS contract after gateway is approved (example)
   node evm/gateway.js -n optimism-sepolia --action execute --messageId [message id] --sourceChain axelarnet --sourceAddress axelar10jzzmv5m7da7dn2xsfac0yqe7zamy34uedx3e28laq0p6f3f8dzqp649fp --destination [destination its contract] --payload [payload]

Send Token

1. Initiate the token transfer to a remote chain (example). The tokenId needs to be provided:
   node evm/its.js -n avalanche-fuji --action interchainTransfer --tokenId [tokenId] --destinationChain optimism-sepolia --destinationAddress 0xba76c6980428A0b10CFC5d8ccb61949677A61233 --amount 1
2. Follow the same steps as above to route the call via ITS Hub to the destination. Note the message id for the contract call in this case.
3. Example ITS hub execution
4. Execute the transfer on the destination ITS (example)

[blockchainguyy]

Configure remote chains to route via ITS hub (run this for each remote chain you want to connect to):
node evm/its.js -n [chain] --action setTrustedAddress --trustedChain [remote chain, e.g. avalanche-fuji, xrpl] --trustedAddress hub

@milapsheth Should we make it trustedChains and allow multiple chains as an input?

[milapsheth]

Configure remote chains to route via ITS hub (run this for each remote chain you want to connect to):
node evm/its.js -n [chain] --action setTrustedAddress --trustedChain [remote chain, e.g. avalanche-fuji, xrpl] --trustedAddress hub

@milapsheth Should we make it trustedChains and allow multiple chains as an input?

Yeah, would be a nice improvement. We should add a specific new action that sets the trusted address to hub for one or more chains and avoids user error. This action can stay as-is since different chains can have different addresses if using the legacy approach.