Fix batcher queue ord

Description

There was a bug in the batcher queue ordering of elements, which led to a wrong placement of proofs when a same sender sent proofs with same max_fee.
The consecuence of this bug was seen when the batcher queue is filled, the proofs sent to chain will be not from lowest to highest nonce, but the other way around.

To Test

You can view the unit tests.

Also you can add the following print statements (and can do before this PR so you can verify the bug indeed existed).

in batcher/aligned-batcher/src/lib.rs, line 1175:

        info!("resulting:");
        for (entry, _priority) in resulting_batch_queue.iter() {
            info!(
                "nonce: {:?}, max fee: {:?}",
                entry.nonced_verification_data.nonce, entry.nonced_verification_data.max_fee
            );
        }

        info!("finalized:");
        for entry in finalized_batch.iter() {
            info!(
                "nonce: {:?}, max fee: {:?}",
                entry.nonced_verification_data.nonce, entry.nonced_verification_data.max_fee
            );
        }

in messaging.rs, line 161:

        info!("Last proof nonce: {:?}", last_proof_nonce);
        info!("Current proof nonce: {:?}", batch_inclusion_data_message.user_nonce);

This will help to view the resulting state of the batcher queue.

To execute the bug you should send a burst bigger than the batch_qty limit. For this it is recommended to lower this value, config-batcher.yaml:

  max_batch_proof_qty: 5 # 5 proofs in a batch, for testing

Then send a burst of size 8, so that the first batch is of size 5 and the second of size 3. (this ensures you don't get the batch already submitted contract revert).

For this you can set BURST_SIZE ?= 8 in the Makefile.

Type of change

• New feature
• Bug fix
• Optimization
• Refactor

Checklist

• “Hotfix” to testnet, everything else to staging
• Linked to Github Issue
• This change depends on code or research by an external entity
  • Acknowledgements were updated to give credit
• Unit tests added
• This change requires new documentation.
  • Documentation has been added/updated.
• This change is an Optimization
  • Benchmarks added/run
• Has a known issue
  • Link to the open issue addressing it
• If your PR changes the Operator compatibility (Ex: Upgrade prover versions)
  • This PR adds compatibility for operator for both versions and do not change batcher/docs/examples
  • This PR updates batcher and docs/examples to the newer version. This requires the operator are already updated to be compatible