The L2ChugSplashDeployer currently comes with two functions cancelTransactionBundle and overrideTransactionBundle that allow the owner of the contract to halt upgrades that are already in progress. We intended these features to be a backstop against any sort of bug that would cause us to publish a faulty transaction bundle and unintentionally brick the system.

Some technical restrictions make these functions difficult to support in practice. Specifically, we've found that these functions don't play nice with #892 (feat[contracts]: add ability to pause EM during upgrades) because the method by which we "pause" the system forces all transactions to be routed through the L2ChugSplashDeployer. This has the (intended) effect of preventing any L1 => L2 messages from being relayed to their target contracts. However, cancelTransactionBundle and overrideTransactionBundle were designed to only by triggered via an L1 => L2 message. In order to support these functions, we'd need to add a non-trivial amount of complex logic to the L2ChugSplashDeployer (which is something we're desperately trying to avoid doing during an upgrade).

This issue is intended to act as a place for discussion about whether or not we can safely move forward by removing the two mentioned functions. This would have the following set of effects:

1. Significantly reduced complexity in L2ChugSplashDeployer.
2. No way to cancel upgrades that have already been started.

Although point (2) is potentially scary, I personally feel that we should absolutely never be triggering an upgrade that needs to be cancelled. Upgrades should be double, triple, and quadruple checked. Every mainnet upgrade should be independently verified by each multisig participant (if not by the community at large). Furthermore, it's unlikely that these functions will be useful for cases in which the transaction bundle is valid (you can actually execute actions inside the bundle) because our automation will likely execute the bundle before we even notice something is wrong. The only case in which I can see these functions being potentially useful is if we were ever to sign off on a random hash that can't actually be used as part of a Merkle proof. This seems like such a dramatic failure that we should aim to avoid it at all costs.