Outbound with gas limit too low should not block outbounds

[lumtis]

Some context here: https://github.com/zeta-chain/node/issues/3723

Some cases were outbound gas limit is too low, the outbound will never be signed, blocking all subsequent outbounds to be processed.

Expected behavior

If the gs limit is too low for some reason, the transaction should simply be failing, reverting and allow subsequent outbounds to be processed.

Possible solution

• Change some parameters to allow the tx to still be processed despite the gas limit and let it fail (might not be possible if the error is purely on the EVM network side, not letting the tx go through)
• If the error is detected, the ZetaClient sign a cancel tx instead to let the nonce get increased.

Note: for now we can tweak the gas limit to be used by default for withdraws, the issue is therefore generally mitigated and not a high priority for the functioning of the network.

[kingpinXD]

The naming used for the current fix might be a bit misleading.

isWithdrawWithNoCall := !cctx.IsCurrentOutboundRevert() && cctx.InboundParams.IsCrossChainCall
isRevertWithNoCall := cctx.IsCurrentOutboundRevert() && cctx.RevertOptions.CallOnRevert

Since we are checking the limit before the contract call, it would be good to have the name reflect that or add some comments.

cc @ws4charlie

[ws4charlie]

The suffix NoCall confused me a bit at first look here

[lumtis]

Keep in this coming release but need some investigation on the complexity

[kingpinXD]

The low gas limit check on the client is not needed anymore, we already check the gas limit before creating the outbound https://github.com/zeta-chain/protocol-contracts/blob/48ecdbcc4c30a8e8a7f2f5756b6a544b316670a0/contracts/zevm/libraries/GatewayZEVMValidations.sol#L40-L42

Also In my opinion the interinsic gas error cannot be triggered total gas = 21000 + call data gas but we have a limit of 2880 for the call data , which is not enough to use up the entire 79,000 reamining gas .

[kingpinXD]

We can rule out intrinsic gas too low as an issue , however the current scheduler by design would keep retrying if for some reason the broadcast or validation fails . https://github.com/zeta-chain/zeta-node/blob/83956ea39d3c2ad0adf2037da2d435e4915fe637/zetaclient/chains/evm/evm.go#L114-L114

THis is not a problem if the broadcast is successull and the tx itself fails .

A good waut to mitigate this , is to keep a track of number of retries per outbound id , and just fail / abort . if the retry count exceeded . I dont think its needed at the moment but would be good to have