Tracking Issue: support IBC integration in Astria

[hdevalence]

Astria is using the Penumbra stack to build their sequencer. They'd like to be IBC-enabled, and last Thursday we had a meeting (cc @noot) about what would be required for them to integrate our IBC stack. We'd like to support them in this, but there will be some work required on both sides. This issue tracks that work.

Currently, our IBC stack has two parts:

• ibc-types, which just does common modeling for IBC data types and messages;
• penumbra-ibc, which implements IBC on top of the state model provided by penumbra-storage and the component system provided by penumbra-component.

Since moving to our own IBC stack as part of #2379, we've hoped to generalize Penumbra's IBC implementation, with the long-term goal of separating the IBC logic from the state access. We've held off on doing it until there's a concrete user, to avoid building the wrong generalization.

However, supporting Astria doesn't require that all of that work, because Astria already uses (some of) the Penumbra stack, in particular penumbra-storage and (a tweaked version of) the Component trait in penumbra-component. Instead, we just need to break the dependency of penumbra-ibc on other Penumbra components and generalize it for Astria's use case:

• Add substore support to penumbra-storage #3129
• ics23: make get_with_proof return a list of proofs #3326
• Determine changes to the Component trait needed for Astria to use it directly #3126
• Design a mechanism to allow dynamic AppHandlers in the IBC component #3127
• Reverse dependency relationship between penumbra-ibc and penumbra-shielded-pool #3128
• Move key/value RPCs into storage crate #3130

Beyond the state machine implementation, there's also relaying support. Much of the work we did on the Penumbra side to support Penumbra integration into Hermes will be directly reusable: the bulk of the work was implementing GRPC queries, and those query implementations are part of the IBC component now, so they can be directly used by Astria.

Astria will need to write their own ChainEndpoint implementation, but other work we're planning to push on in order to support Penumbra integration into Hermes may be useful to Astria:

• Change config format to scope configs by type informalsystems/hermes#3636 (comment) allows Hermes backends to have backend-specific configuration data
• ChainEndpoint trait makes restrictive assumptions about signing keys informalsystems/hermes#3641 may be relevant, depending on Astria's account / signing model.

The Astria team indicated they were hoping to get token transfers working by the end of October (4 weeks from now), so we should coordinate closely to make sure we're not blocking their work. (We missed this timing because the substore work turned out to be more complicated than expected, but we still want to get this over the finish line ASAP).

To exercise this end-to-end, we should aim to make an IBC connection between an Astria devnet and a Penumbra devnet. Checklist:

• Rebase/Rebuild Penumbra Hermes support on top of backend-specific configs #3477
• IBC: implement Astria ChainEndpoint into Hermes astriaorg/astria#561
• Create a Hermes branch that merges Astria support branch + Penumbra support branch #3888
• Manually exercise IBC relaying between Astria devnet + Penumbra devnet.

[conorsch]

We've spoken with Astria out of band, and we have a few more weeks to get the necessary functionality in place. Related work such as #3131 is not shipping in Testnet 62 (#3123), but we plan to return to it soon.