Bug in transfer module for IBC Eureka

[AdityaSripal]

IBC Eureka no longer prenegotiates channel fields before enabling packet flow. This not only means that the version in the packet is unnegotiated, but the <portID, portID> pairing is also unnegotiated.

Thus on a given Eureka channel; any application can send packets to any other application.

This means that multiple application senders can send to the same transfer destination port on the receiver.

The way that transfer differentiates denoms is to only use the destination port and destination channel. This worked in IBC v1 because there was a tight coupling between channelIDs and also a tight coupling between portIDs.

Now that the coupling between portIDs is being relaxed, this no longer works because tokens sent from different applications on the same sender chain to the transfer receiving application will all be mixed together. Different apps on the sender chain are not mutually trusted (especially for smart contract chains).

We need to fix this for the new transfer application by including srcPort, destPort and destChannel in the denom when receiving a token.

We need to particularly consider how to deal with backwards compatibility in this case. Perhaps the best thing we can do is maintain an internal mapping in transfer from the new IBC traced denom to the original iBC hashed denom that only contains the destPort