fix: use exponential backoff parameters correctly

[JuArce]

fix: use exponential backoff parameters correctly

Description

The general rules for retries logic is the following:

• Ethereum transactions should use a special set of parameters (MinDelayChain, MaxIntervalChain). This is a retry on 12, 24, 48s, ...
• Waiting for transaction receipt will use the following rule: Retry times: 0.5s, 1s, 2s, 2s, 2s, ... until it reaches waitTimeout
• All other calls to services like S3, or ethereum calls, use a default set of parameters (MinDelay, MaxInterval). This is a retry on 1, 2, 4s, ...

Closes #1406

Type of change

• Bug fix

How to test

In devnet

1. make anvil_start_with_block_time
2. make aggregator_start
3. make operator_full_registration CONFIG_FILE=config-files/config-operator-1.yaml
4. make operator_start CONFIG_FILE=config-files/config-operator-1.yaml
5. make batcher_start_local
6. make telemetry_full_start

Once you have the system running, send proofs

7. make batcher_send_burst_groth16
8. Go to jaeger http://localhost:16686/search
9. You should see the traces correctly created and task verified

In staging

Deploy the aggregator in staging and check the metrics are correct.

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