refactor(worker): order L1 messages by queue index

[Thegaram]

1. Purpose or design rationale of this PR

TransactionsByPriceAndNonce is a data structure used to order transactions by gas price and nonce. The idea is that we can process transactions from one account following their nonce order, and we can simply skip all transactions from an account if one in the middle is not executed. If all gas prices and nonces are equal, then it will order transactions based on their timestamp.

We currently reuse TransactionsByPriceAndNonce for processing L1 messages. However, L1 messages are ordered by their QueueIndex. Gas prices and nonces for L1 messages are 0, and the worker ensures that the timestamps follow the QueueIndex order so this all happens to work.

However, this is hacky and error prone for multiple reasons:

• It is non-trivial to see that the order of processing L1 messages is correct. This was actually raised as a false positive critical finding during an audit. We added a test TestTransactionTimeSort to verify this behaviour.
• We should ensure to never call Pop() on an L1 message set. In other words, we should only skip a single L1 message and never skip all L1 messages from the same sender account. Otherwise we might skip L1 messages unnecessarily.

This PR improves this by introducing a new interface OrderedTransactionSet. worker.commitTransactions will now receive this interface. It has two implementations: TransactionsByPriceAndNonce (used for L2 transactions) and L1MessagesByQueueIndex (used for L1 message transactions).

2. PR title

Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:

• refactor: A code change that doesn't fix a bug, or add a feature, or improves performance

3. Deployment tag versioning

Has the version in params/version.go been updated?

• This PR doesn't involve a new deployment, git tag, docker image tag, and it doesn't affect traces
• Yes

4. Breaking change label

Does this PR have the breaking-change label?

• This PR is not a breaking change
• Yes