feat(aggregation-mode): integrate proof aggregator with db

[MarcosNicolau]

Description

Integrates proof aggregator with Batcher db. Now the ProofFetcher instead of fetching the proofs from the verification layer (a.k.a fast mode) queries them from the DB managed by the AggMode Batcher. This process is as follows:

1. Select proofs from a proving system (SP1 or Risc0 depending on how the program was started) up to a limit and mark them as processing so concurrent aggregators won't try to aggregate the same proofs
2. Aggregate them
3. Submit it to Ethereum
4. Store the merkle path for each proof and mark them as verified

This is an initial version to integrate everything and have something to iterate upon:

• If there is an error, set the proofs back to pending state to make sure they are aggregated by another proof aggregator
• Improve queries: I didn't quite review the performance of the queries and how they might impact when we are aggregating a higher number of proofs
• Maybe add intermediate states for the proofs (verified, submitted, etc).

Notes:

• The elf field for the SP1ProofWithPubValuesAndElf has been removed and renamed to SP1ProofWithPubValuesAndVk. This is because we don't need the elf anymore since now we can get the VerifyingKey from the request saving us from the overhead of having to setup the client. I was doubtful when implementing this but it seems that sp1 does the same in the prover network see here.

How to test

1. Checkout to feat(agg-mode): receive proofs via mutlipart form data instead of json in batcher #2192 and follow the instructions to add proofs to the DB via files:

git checkout feat/receive-proofs-via-mutlipart-form-data

2. After that, aggregate them

make proof_aggregator_start_ethereum_package

3. Verify their status is processing in adminer or psql
4. After aggregation, query their respective merkle proofs:

curl -X GET  'http://127.0.0.1:8089/proof/merkle?id=<TASK_ID>'

Type of change

Please delete options that are not relevant.

• New feature

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 crates/docs/examples
  • This PR updates batcher and docs/examples to the newer version. This requires the operator are already updated to be compatible