fix: send aggregated response bump

[MarcosNicolau]

Description

Fixes aggregator bump fee by adding the following checks:

• The newly bumped gas price is at least 10% higher than the previously sent transaction.
• If the receipt wait timeout for a tx has passed, save the tx.
• On the next iteration, before sending the transaction, loop through the vector and try to get the receipt again.
• If the receipt is not found, check if the batch is marked as responded in the contract
• If all that fails, send the transaction again with the newly bumped gasPrice.

Finally, tracing has been improved by adding step-by-step logs with the respective merkle root hash.

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

[MauroToscano]

In review by Pelito

[Oppen]

LGTM.
Two issues to file:

1. Sequential requests quadratic to the number of attempts. This can be postponed because it requires several attempts to be an issue, potentially many, so we're likely under a more problematic scenario than some slowness already.
2. Metrics for the number of attempts and tracing would be more desirable than just logging (in fact, if we need to choose only one, tracing is better). This include events and spans, but can be a later refinement as well. That will help with diagnosis if this becomes a bottleneck.