Aliasing new approach

[AdityaSripal]

We internally discussed different approaches to aliasing v1 channels to v2 and weighed the potential complexities in ibc-go with the potential complexity of retaining a channel layer for new users of IBC.

We decided that having a channel layer was unnecessarily complex for new users, and that conceptually the idea of creating two clients and then directly connecting them together was much simpler. Thus, we are moving back to the CounterpartyInfo struct that we had discussed before which will be keyed directly against the clientID.

There will thus, only be two clients and counterparty information signalling the path to verify against. The packet handlers will remain and will directly retrieve and use these structs for processing.

We will also retain the idea that there is only a single identifier to create a Eureka connection between two chains in the standard case (rather than having a client identifier and a separate channel identifier)

In order to support existing channels, we will create an exceptional case handling in ibc-go that will create a direct map from the channel-id to the clientID to retreive the underlying client and counterpartyInfo

The counterpartyInfo itself should have only the merklePathPrefix and the counterpartyId

The counterpartyId is to be interpreted as the provable path under which the counterparty will write all outgoing packet messages toward us.

Thus, in the aliasing case; the counterpartyId should be the counterparty's original channel-id since the counterpartyId need not be strictly linked to the clientID.

Furthermore, given the new key formats introduced in cosmos/ibc#1155 and the changes we made to supporting broader tree types; we should be able to have just a single field of the counterpartyId which should be explored by the implementor writing up this approach.

[damiannolan]

Is the intended approach here to keep the existing msg server apis in 04-channel/v2?

This may just be more refactoring but it might be better in this case to not use 04-channel/v2 as a place to maintain the new code. If the intended desire is to not cause confusion and complexity around maintaining the concept of a channel in ibc/v2.

I think the concept of a v2 channel being represented as the pairing of light clients on opposing chains was easily grokable but maybe to some this is confusing.

If we move away from the concept of a v2 channel entirely then IMO it might be best to split the ibc/v2 code out completely away from 04-channel. Start with a flat enough go pkg structure and organise things as needed. This will likely take more dev time but in the long run I would like to see ibc/v2 as a new, separate go module from ibc-go classic. I think its a great opportunity to develop a more robust set of go modules which make up ibc/v2 and its apis.

I think it should be possible to deliver an implementation of ibc/v2 within ibc-go as it currently exists today. And then later on, develop a new go module which is state and protocol compatible to move forward with.