Prevent loops in revert messages when cross-msg fails to be applied

[adlrocha]

When a subnet fails to apply a cross-msg, it creates a the opposite cross-message to revert potential state changes and funds that may have been frozen in the message transit to destination. A problem appears if this message is malformed and the "reversion" message also fails when being applied in the source, as this will trigger another "revert messages" to the source, and the cross-message will enter in a loop where it goes back and forth without ever being applied. This can be a huge DDoS attack vector.

https://github.com/filecoin-project/eudico/blob/cb44e617037daa8c63076cf335e3c4a4bd72235d/chain/consensus/hierarchical/actors/sca/sca_apply.go#L170

We should improve the logic of revert transactions so:

• Reverting the state changes from a failing cross-message should only be attempted once. If the message fails in the source, then we discard the cross-message and do nothing. Revert ,essages include error information in their params, so we can identify this type of messages.
• Only trigger revert messages if msg.Value != 0. Cross-messages do not perform any state changes in the source, which means that if the message fails in destination there's nothing to revert in the source. This is not the case for messages with msg.Value != 0 as these required the locking and minting of funds in the SCA to move them around subnets.

[adlrocha]

The Rust implementation (FVM) of SCA is pending the implementation of noop so we can discuss and figure out the best strategy to tackle this: https://github.com/adlrocha/builtin-actors/pull/3/files#diff-a190aefdce5d1b0118619083153decf4dc807aa5ccddfeb7daae9836091de569R613

[adlrocha]

See https://github.com/protocol/ConsensusLab/discussions/119 and spec to see the implementation proposals.