Consider whether to remove IBC acknowledgement in IBC v2

[soareschen]

Following the discussions in #1149, I am wondering if it makes sense if we should altogether drop the support for IBC acknowlegement in IBCv2, and have a simpler uni-directional message-passing semantics.

The main reason for this consideration is that the logic for committing an acknowledgement in the presence of error is very hard to get right, and it is not universally supported on all non-Cosmos blockchains. The problem is that most blockchain application logic is written with the assumption that in case there is an error, the transaction atomicity will help rollback and clean up everything. But with error acknowledgement, it requires the overall transaction to succeed to commit the ack, thus making it challenging to rollback any application-level error.

On the other side, the semantics for handling acks on the source application is also not very reliable, especially in the presence of multiple payloads in v2. Here we also run into the problem that an ack can only be registered if the transaction succeed, but if any application failed when handling the acks, then it needs to rollback.

A simple strategy which we can workaround this is to allow the whole transaction to fail, and let the packet time out. But if we choose that as the main strategy, then it makes little sense to use the ack to signal any error. On the other hand, if we only use acks when an application succeed, then the application could have easily just send a normal IBC packet back to the counterparty in case it really needs to respond to anything.

With the removal of acks, we can significantly simplify the protocol, so that applications can assume that the packet is sent successfully, unless it timed out. If an application do not have any response to return, it can simply process the packet without sending anything back. We should also add a field to the IBC packet to allow applications to ignore a timeout, in case when it doesn't care whether the packet is eventually received by the counterparty. With this, the original ack simply becomes a normal IBC packet in the reverse direction that ignores timeout.

Another potential benefit of this model is that for multi-payload packets, the response should be split back into multiple single-payload packets. This way, we don't need to worry about the atomicity of ack handling, and each application can choose whether to send back an ack response, with or without ignore-timeout.