Change config format to scope configs by type

[hdevalence]

Summary

Currently, Hermes' ChainConfig is one monolithic structure with many options. Although it has a type field specifying the chain type, it's not possible to have different config options depending on the chain type. To fix this, and ease the way into Hermes support for non-SDK chains, it would help to restructure the config format so that configuration options are scoped by chain type.

As an example of the kind of problem this creates, consider the changes in penumbra-zone#3 . This option is Penumbra-specific, so it should only be present when configuring a Penumbra chain -- it doesn't make sense that all other places where the config is used should have to include a Penumbra-specific option. And many of the options in the existing ChainConfig are actually specific to the Cosmos SDK, and are ignored by our Penumbra ChainEndpoint implementation.

Instead, if the config were an enum:

• Each "backend" can define their own configuration structure, with only the options relevant to that backend;
• The top-level config can be an enumeration of all of the backends included in Hermes.

The enum can be nicely represented in a TOML config file using Serde attributes, in particular using Serde's tag attribute. To see an example of how this works in practice, look at the authorization policy configurations for Penumbra's SoftKms software key-management service, documented here and implemented here:

[[kms_config.auth_policy]]
type = 'DestinationAllowList'
allowed_destination_addresses = ['penumbrav2t13vh0fkf3qkqjacpm59g23ufea9n5us45e4p5h6hty8vg73r2t8g5l3kynad87u0n9eragf3hhkgkhqe5vhngq2cw493k48c9qg9ms4epllcmndd6ly4v4dw2jcnxaxzjqnlvnw']

[[kms_config.auth_policy]]
type = 'OnlyIbcRelay'

[[kms_config.auth_policy]]
type = 'PreAuthorization'
method = 'Ed25519'
required_signatures = 1
allowed_signers = ['+Osq5OiWKos57KigDjd3XCG/YLUOSUbuBly4LBBpJTg=']

In the config file, the enumeration is collapsed into the type or method tags, so the user doesn't need to consider nested enums, but the code can have options scoped to the specific backend provider.

Doing this would be a small and incremental step towards multi-chain support for Hermes.

Acceptance Criteria

Hermes' config format is an enumeration with config options that can be set per chain type.

---

For Admin Use

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

[romac]

Agreed, this would indeed make more sense than the monolithic config we have now. We're a bit swamped in Q4 so I can't promise we'll manage to get to it this year unfortunately. We'll keep you posted!

[seanchen1991]

We'll definitely consider structuring config files with the Hermes SDK in this way 👍

[hdevalence]

I'd be happy to send a PR, we'll need something like this for our Hermes support in order to not have a bunch of meaningless options, so it'd be just as well to send it upstream.

[romac]

That would be amazing! 🙌

[hdevalence]

Some work on this here: #3644

The tests in the core relayer crate all pass, but the cli doesn't build. There are some issues with the cli baking in assumptions about the SDK that I'm not sure of the best way to resolve. Once the CI runs, I can leave those comments.