Interop: handle deposit-tx invalid executing message (post-3074)

[protolambda]

With the changes for 3074 executing messages are now log-events. This prevents us from filtering the deposit-txs upfront during derivation, and instead the execution-engine has to filter/handle the transactions.

Deposit-txs may only consume initiating messages that are older than the sequencer-window, to guarantee the inclusion of the initiating message side synchronously (sequencer cannot censor deposit txs).

With a filtering approach of deposits, the message-consolidation will also mismatch.
Instead we may want to change the deposit-tx to "failed" status, to revert the changes but retain the tx, such that block-consolidation can stay the same. And no assumptions around L1 bridge to L2 deposit-tx lookups will break.

[protolambda]

If we change the deposit-tx failure state based on interop, then we also have to be able to replicate this during tx-tracing and block re-processing (reorgs, historical state queries on full nodes, etc.)

[tynes]

A solution for this is proposed in ethereum-optimism/design-docs#13 but it needs to be improved to remove the requirement of requiring an archive node for historical sync. This is definitely possible, more thought needs to be put into it.

The scope of allowing executing messages to be triggered from deposits is cut from the scope of the devnet. The devnet will simply ban deposits that trigger executing messages for simplicity

[tynes]

Moving this to the testnet milestone as now we have a smaller scope devnet solution

[tynes]

Going to close this issue as we are no longer going to try to solve this as part of the initial devnet release. We will not allow for deposits to trigger executing messages for the initial release