Refactor openIbcChannel and connectIbcChannel to align with IBC standards

[zhengyangfeng00]

Background

In IBC standards, there are four steps in the handshake: openInit, openTry, openAck, and openConfirm.

A straightforward implementation for an IBC module would be to define four methods to handle the four steps. The relayer would then pick one to call depending on the state and who is the initiator of the connection.

However, in most cases, a user's smart contract does the same thing in openInit and openTry, and the same thing in openAck and openConfirm.

To provide a better development experience for the user, the vibc core SC requires the user's SC to implement only two callbacks: onOpenIbcChannel and onConnectIbcChannel.

The current implementation is as follows:

• vibc core SC implements openIbcChannel, which is called in both openInit and openTry.
• vibc core SC implements connectIbcChannel, which is called in both openAck and openConfirm.
• openIbcChannel calls onOpenIbcChannel from the user's SC.
• connectIbcChannel calls onConnectIbcChannel from the user's SC.

Problem and the proposed implementation

This has caused difficulty in implementing the state verification logic. In connectIbcChannel, we don't know if the method is called as the connection initiator or acceptor, and we don't know the state to verify. It could be either Ack_Pending or Confirm_Pending.

The proposed refactor is to split openIbcChannel into connOpenInit and connOpenTry, and split connectIbcChannel into connOpenAck and connOpenConfirm.

The user's SC still only needs to implement two methods, which provides the same development experience as before. This change will allow us to solve the state verification issue and better align with IBC standards.