fix(batcher): non paying proofs are ignored when queue is full

[JuArce]

Non paying proofs are ignored when queue is full

Description

When the queue is full, non-paying proofs were being ignored

This PR fixes that by performing replacement on low-fee proofs

How to Test

1. Run Ethereum-Package

make ethereum_package_start

2. Set max_queue_size: 10 in config-batcher-ethereum-package.yaml

3. Run batcher

make batcher_start_ethereum_package

4. Create a wallet with the following private key (anvil address 7)

cast wallet import anvil_7 --private-key 0x4bbbf85ce3377467afe5d46f804f221813b2bb87f24d81f60f1fcdbf7cbf4356

5. Fund the batcher with this keystore

aligned deposit-to-batcher \
--rpc_url http://localhost:8545 \
--network devnet \
--keystore_path ~/.foundry/keystores/anvil_7 \
--amount 0.1ether

6. Send proofs with low fee to fullfil the queue

aligned submit \
--proving_system Risc0 \
--proof ./scripts/test_files/risc_zero/fibonacci_proof_generator/risc_zero_fibonacci_2_0.proof \
--vm_program ./scripts/test_files/risc_zero/fibonacci_proof_generator/fibonacci_id_2_0.bin \
--public_input ./scripts/test_files/risc_zero/fibonacci_proof_generator/risc_zero_fibonacci_2_0.pub \
--aligned_verification_data_path ~/.aligned/aligned_verification_data \
--keystore_path ~/.foundry/keystores/anvil_7 \
--network devnet \
--rpc_url http://localhost:8545 --repetitions 10 --max_fee 0.000000000000000001ether

7. Send proofs with the non-paying address

aligned submit \
                --proving_system SP1 \
                --proof ./scripts/test_files/sp1/sp1_fibonacci_4_1_3.proof \
                --vm_program ./scripts/test_files/sp1/sp1_fibonacci_4_1_3.elf \
                --repetitions 10 \
                --proof_generator_addr 0x66f9664f97F2b50F62D13eA064982f936dE76657 \
                --rpc_url http://localhost:8545 \
                --network devnet

anvil_7's proofs should be replaced with non-paying proofs and the the batch should be created

Type of change

• Bug fix

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