Revert state changes in source subnet if cross-msg can't be applied in destination

[adlrocha]

In order to execute cross-msgs, we need to implicitly call ApplyMsg for the SCA to trigger the corresponding state changes in the destination subnet. ApplyMsg expects cross-msgs to be applied sequentially one-by-one, which means that if a cross-msg validated in a block is malformed, and calling ApplyMsg fails, the consensus of the subnet will be stalled as it'll keep trying to apply a malformed message for the same noce. It may be hard for this to happen because cross-msgs follow several checks in their path to the consensus, and nodes shouldn't accept blocks for which one of the included cross-msg fails, but even with all of these checks there is a possibility for a wrong cross-msg to make it to the consensus.

To avoid the subnet consensus from stalling, the current implementation of the SCA applies a noop function and increments the applied nonce instead of aborting to discard the message and keep the protocol alive. Discarding the malformed message fixes the liveliness issue, but introduces an inconsistency, in which the state changes in the source subnet have been applied (like the freezing of funds), but the consequences of the operation are not triggered in the corresponding destination subnet (the one unable to apply the message). Consequently, it would be good to have in place a mechanisms to notify malformed messages to the source so it can revert the state changes for the message that failed to be applied in destination.

Let's put a Fund message as an example. A user sending a Fund message in a subnet triggers the freezing of a number of funds, and the minting of new funds in the destination subnet when the cross-msg is accepted. If the message can't be applied in the subnet, the cross-msg will be discarded without minting the funds in the destination subnet, but keeping the funds from the source subnet frozen. In reality, funding is an atomic operation and this won't be the case, but this issue can arise when executing arbitrary cross messages, or trying to route a message to a non-existing subnet. We can maybe handle this by enforcing the checks as much as possible in the source to ensure that cross-msg being executed will always be applied. But again, it would be good to have a scheme in place to revert potential inconsistencies.

[adlrocha]

A perfect example where this could happen is when trying to route some message to a non-existing subnet. The previous subnet in the path to the non-existing subnet will try to forward to the right subnet but it won't find it registered in SCA.

To revert all state changes performed in the messages path to the non-existing subnet, the SCA will trigger the opposite cross-net message (switching to and from) when it can't apply the message. This notifies the source that the transaction couldn't be committed and reverts all state changes triggered in the path of the message to its destination.