Describe the bug
Verifiers will

1. Passively observe Ethereum contracts
2. Compute the resulting state of rolled up transactions by using the OVM geth fork
3. Prove fraud resulting from a mismatch between claimed resulting state and computed resulting state

Batches of rollup transactions will likely contain more than one rollup transaction (that's the whole benefit of Optimistic Rollup), and these transactions will need to be processed by the OVM geth fork in order of batch number, followed by index within batch.

At the moment, the mechanism by which order is enforced in transmitting transactions to the OVM geth fork does not work and assigns all transactions within a batch the same index

Steps to reproduce
Steps to reproduce the behavior:

1. Run a verifier pointing at contracts with rollup transactions posted (starting at an L1 block number before they were posted)
2. Verify that l1_rollup_tx entries all have an index_within_submission of 0

Expected behavior
The l1_rollup_tx.index_within_submission should be unique in combination with geth_submission_queue_index, and the first transaction in the rollup batch should get index 0, the second gets index 1, and so on...