Implement abstract components to support ISC29 incentivized packet relaying

[soareschen]

Summary

With the upcoming use of ICS29 on major chains, the relayer needs to implement various logic to support new use cases that are based on incentivized packets. Although these features may be implemented in the current v1 relayer, it may require significant changes to the code, depending on how complex is the logic. If there is sufficient time before ICS29 is used, we may be able to implement the complex features in relayer-next only, thus simplifying the development requirements.

Details

In this issue, we will draft out the abstract components that can be used to support incentivized packet relaying. At the same time, these components will remain abstract, i.e. not integrated into the all-in-one traits and Cosmos implementation. This will speed up the time needed to design the components. Once the abstract components are implemented, they can be integrated with the concrete implementations in separate issues.

List of tasks

• Introduce incentivized packet event with HasIncentivizedPacketEvent: HasIbcEvent trait.
• Introduce abstract token types with HasTokenTypes trait with associated types like Denom and Amount.
• Define CanQueryIncentivizedPacket trait that queries on whether a packet is incentivized and return the fees.
• Define CanRegisterCounterpartyAddress trait for registering counterparty address.
• Implement a PacketFilter component that filters incentivized packets.
• Implement an EventRelayer component that reacts only on IncentivizedPacket events, as compared to SendPacket events.
• Implement a PacketRelayer middleware that waits for a packet to get incentivized before calling the inner packet relayer.
• Implement a RelayBuilder middleware that automatically register the counterparty address after building a relay context.