feat: scaffold IBC module and IBC packets

[lumtis]

starport module create <module-name> --ibc creates a module with standard placeholders to implement an IBC module

Optional flag --ibc-ordering [none|ordered|unordered selects the ordering of the channels

starport ibc packet <module-name> <packet-name> field1 field2... creates for the module a packet that can be send over IBC with custom data

This packet generates a new tx:
appd tx <module-name> send-<packet-name> [src-port] [src-channel] field1 ... that allows to send the packet to a channel

(This tx generation will be optional in the future since sometimes packet emission can sometimes be triggered by on-chain logic)

Everything is generated for the developer, this only thing left for them to customize:

• eventual channel handshake additional logics
• action when a packet is received
• action when a packet is acknowledged
• action when a packet timed out

To fix:

• Can't send message from client 2 (eventually a problem from relayer or when using twice the same chain locally)
• Acknowledgment hooks not triggered
• Packet timeouted sometimes before the default threshold of 10 minutes
• Error when setting timeout to 0 (while it should disable the timeout)

[lumtis]

I was thinking first of having a first PR with only one generated packet and, afterward, implement packet creation with Starport with a command but actually, it would involve having placeholders that would be then replaced.

It's better to atomically push the packet creation command with the whole IBC module creation feature. It would be a command that takes the data that compose the packet and generate everything for sending the packet in a method SendFooPacket in the keeper. This method can then be called in a handler to perform the IBC transmission.
It would also generate the type dispatcher when a packet is receiving.

Ideas for the format of the command? Since a packet is a type, I am thinking we could transform the type command into a whole namespace and have everything related to type generation in this namespace.

Therefore we could have:

starport type crud post text --module blog
starport type packet post text --module ibcblog

Any opinion on this @fadeev @ilgooz @clockworkgr ?

[fadeev]

I propose starport packet post text --module ibcblog. We don't want to modify the type command just yet and packet is substantially different from type (it doesn't add crud, right?).

The general idea is that we add features trying not to modify the existing command set of Starport. Once we get closer to 1.0 and we understand exactly the functionality that Starport will provide, we'll reorganize commands into a better system in a single release.

[lumtis]

I agree we should avoid changing the design of the command whenever possible.
The idea for the namespace is if we plan in the future to continue to enrich the scaffolding feature, we are likely to consider other type generation possibilities and then all of those types of command should be inside the same namespace.

One another simple example is about scaffolding a type without CRUD operations, where you simply have the keeper methods to set the type, delete, etc. but not the generated transactions. For me it is not intuitive that type directly means having CRUD operations.

If we consider IBC packets should not be linked to this namespace I'm ok with this. Although I would consider directly allocating a new namespace for every IBC related commands in the future starport ibc packet ... --module foo

[fadeev]

Right now we're adding packets to the same types/packet.go file with a string replacement. Wouldn't it be better if we had like packet_post.go and packet_user.go to make it less fragile?

I would also add underscore in cli/txpost.go for readability.

[lumtis]

I got inspired by the structure of ibc-transfer but it's actually better to have the least placeholder as possible for better mainabitlity

[ilgooz]

Great work Lucas!

[fadeev]

This is seriously cool! Can't wait to have "hello world" for IBC 🛰