Investigate using "tagged identifiers" in connection/channel handshake

[plafer]

We recently introduced this naming convention in the handshakes to facilitate understanding the logic. Correctness however still relies on the programmer. We could use "tagged identifiers" (see below) to let the type system tell us if we've made a mistake.

From @romac:

• MonoTagged and DualTagged definitions: https://docs.rs/ibc-test-framework/0.19.0/ibc_test_framework/types/tagged/index.html
• Tagged identifiers definitions: https://docs.rs/ibc-test-framework/0.19.0/ibc_test_framework/types/id/index.html
• Example use in extension trait: https://docs.rs/ibc-test-framework/0.19.0/ibc_test_framework/chain/tagged/trait.TaggedChainDriverExt.html
• Everything relating to tags in the test framework: https://docs.rs/ibc-test-framework/0.19.0/ibc_test_framework/types/tagged/index.html?search=tagged

Also see the typestate pattern.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[plafer]

Another potential use of the typestate pattern would be to tag data as:

• Dirty: comes from user input (e.g. a message), and needs validation
• Clean: has been validated

The goal would be to avoid at compile-time scenarios where e.g. we unwrap() user input (see #219).

Further discussion is required though to see if the added complexity is worth it.

[skaunov]

Should there be one typestate system, or two? (Or other number?)

Correct me if I wrong, please. [connection Opening handshake] defines state automaton with 5 states, and it's the automaton which is implemented by relayer. But in turn it's based on clients state defined in https://github.com/cosmos/ibc/tree/main/spec/core/ics-002-client-semantics#clientstate which also could be represented by an automaton, and these states are used in connection mod. So if typestates would implement [connection Opening handshake] automaton, the types of it would be parallel with State. On the other hand if implementation is based on the States, then the automaton defined in [connection Opening handshake] should be expressed as two interacting automatons, which would define it implementation for connection mod.
[connection Opening handshake]: https://github.com/cosmos/ibc/blob/main/spec/core/ics-003-connection-semantics/README.md#sub-protocols

[plafer]

I don't think the typestate pattern would apply to IBC's "handshake state machine", or at least with very little benefit, since only one step of the state machine is only ever executed at once (that is, per message processed).

Should there be one typestate system, or two? (Or other number?)

Indeed there could be more than 2; basically anywhere we find a new use case where the pattern could be useful.