Describe the bug
We often go over the size limit of transactions when submitting batches. This causes our transactions to fail and generally everyone has a bad day.

Steps to reproduce
Steps to reproduce the behavior:

1. Set the transaction calldata size to a number above 132KB (even slightly below this number)
2. Run the full system
3. Observe errors submitting batches

Expected behavior
We should never submit transactions above the maximum size.

Solution

Work-around

Reduce the Max L2 Tx calldata size for a batch:

1. Update the l2_geth_subscriber 's task definition to have a lower CANONICAL_CHAIN_BATCH_MAX_CALLDATA_BYTES value (right now it's 90,000)
2. Update the ECS service to reference the new task definition and restart the ECS task so it picks up the new config (stop it, and it'll restart itself)
3. Run this query to delete created but unsubmitted batches so that they will be rebuilt to fit the lower size limit:

BEGIN;

UPDATE l2_tx_output
SET 
	canonical_chain_batch_number = NULL,
	canonical_chain_batch_index = NULL
WHERE canonical_chain_batch_number >= *batch number that is erroring*;

DELETE FROM canonical_chain_batch
WHERE batch_number >= *batch number that is erroring*;

COMMIT;

Solution

Since it should be predictable, accurately calculate the total transaction bytes for the L1 rollup tx (including all the rolled up L2 Txs' bytes) and create batches such that this number of bytes is less than or equal to the CANONICAL_CHAIN_BATCH_MAX_CALLDATA_BYTES instead of simply making sure that all of the L2 txs being rolled up are under this number.