Support Evmos in integration tests

[soareschen]

Summary

A number of changes are needed for running ibc-integration-test using evmosd.

Problem Definition

There are a number of incompatibilities when running the current integration test suite with evmosd:

• evmosd requires a very specific format for the chain ID during chain initialization, in the form evmos_9000-{digit}. This is incompatible with the current chain ID used in integration test, such as ibc-0-f5a2a988.
• The address_type field in the relayer config has to be the value:

  config::AddressType::Ethermint {
     pk_type: "/ethermint.crypto.v1.ethsecp256k1.PubKey".to_string(),
  }
  

• The HD Path used for importing private key is m/44'/60'/0'/0/0.

It is also unclear how we can make the above parameters to be customizable when running the integration tests. There are several options available:

1. Introduce new environment variable for each parameter. e.g. CHAIN_IDS, $HD_PATH, $ADDRESS_TYPE.
2. Introduce a test config file to capture all test parameters without environment variables.
3. Special case during test when the chain binary is evmosd. This can be done by turning FullNode and ChainDriver into generic traits, with multiple implementations for different chains.

A further complication is that the parameters need to work with multiple chain binaries that will be introduced in #2003, such as running tests with an Evmos chain connect to a Gaia chain. With that, option 3 seems to be the simplest to implement.

Support for running integration tests with Evmos is required to triage issues such as #2433, and use CI to ensure that IBC relaying from Evmos remain smooth in the future.

Proposal

• Modify FullNode and ChainDriver in ibc-test-framework to work generically and behave differently when the chain binary evmosd is used.

Acceptance Criteria

Tests pass when running:

CHAIN_COMMAND_PATH=evmos cargo test -p ibc-integration-test

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[romac]

I agree that your proposal is probably the best way forward!