Generate distinct Channel/Connection identifiers when running tests

[DimitrisJim]

Summary

Subtle bugs can slip through when we use the same channel/connection (client?) identifiers since many of the verification functions expect those to verify the given proofs. These will work in our testing environment but would fail in the most common real-life case where identifiers are unique.

Case in point: #4052. A similar bug was also found in UpgradeCancel after forcing distinct identifiers for channels.

One possible hacky solution is forcing a channel/connection init in the coordinators functions before actually setting up the connection/channel (hack inspiration #4052 (comment)). This was we ensure distinct connection/channel identifiers for our internal tests.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[DimitrisJim]

we currently make assumptions about channel/connection ids in the tests so maybe not do this for all tests atm.

[chatton]

Definitely like this one, even if we just did a channel id different since we usually do either chain A port/channel ID or counterparty port/channel ID.

[crodriguezvega]

Maybe this is too hacky, but sounds simple to me: before the connection and channel handshakes complete, on one of the chains we write in the nextConnectionSequence and nextChannelSequence keys the value 1, so that when the connection and channel identifiers are generated in the handshake they use that number instead of 0.

[chatton]

Since the channelIDs are generated dynamically in core ibc and we parse them from events in our test, it sounds like @crodriguezvega 's solution seems reasonable to me. A little hacky but I think it is worth it to eliminate this class of error.

[DimitrisJim]

added this to next iteration, both Carlos and Colin pointed out occurrences of this, best to take it on sooner rather than later.