feat: Poll DB and sign L1 batches (BFT-474)

[aakoshh]

What ❔

Implements PersistentBatchStore methods added in matter-labs/era-consensus#148

• Add ConsensusDal::unsigned_batch_numbers to retrieve L1 batch numbers without a QC after a given minimum batch number
• Add Store::unsigned_batch_numbers which return the unsigned batches that are max 10 batches older than the last one
• Add ConsensusDal::get_batch_to_sign after finding out what to put into hash
• Update ConsensusDal::insert_batch_certificate to validate the correct hash value
• Test unsigned_batch_numbers
• Test get_batch_to_sign and insert_batch_certificate
• Point era-consensus at the latest version instead of https://github.com/matter-labs/era-consensus/tree/bft-474-pairing-prev-version then delete that branch

The hash check has been implemented against the StoredBatchInfo::hash() which isn't available in the DAL crate.

Why ❔

The consensus Executor will poll unsigned_batch_numbers and submit attestations over get_batch_to_sign. These methods decide 1) which batches to sign and 2) what content to sign.

Checklist

• PR title corresponds to the body of PR (we generate changelog entries from PRs).
• Tests for the changes have been added / updated.
• Documentation comments have been added / updated.
• Code has been formatted via zk fmt and zk lint.

[aakoshh]

@RomanBrodetski I think it's correct to sign the hash of StoredBatchInfo and not just the commitment field because this is a record that gets converted to RLP before hashing, it's meant to be sent to the L1 contract, and therefore the attestation should cover the whole content, not just one field in it.

It might even be enough to sign just this and not the hash of attester::Batch itself, since it already contains the number. Alas, that would mean we couldn't verify a BatchQC on its own and someone could change the number in it the message.

So Solidity would have to verify something like keccak256(abi.encode([batch.number, keccak256(abi.encode(<stored-batch-info>))])