Implement add_ciphertexts workflow

[goshawk-3]

Description

When SnS workers compute and upload a bootstrapped ciphertext to an S3 bucket, they must notify the transaction sender and share the digest of the uploaded ciphertexts. This should allow the transaction sender to make an attempt to add the tuple (handle, ciphertext128_digest, ciphertext64_digest, key_id) to the Ciphertext Storage in L2 using the ABI add_ciphertext function.

Workflow

1. SnS worker computes 128-bit ciphertext from ciphertext64 (done)
2. SnS worker creates digest of both ciphertexts (using Keccak256) and inserts them into Postgres ciphertexts_digest table
3. SnS worker ensures that both ciphertext64 and ciphertext128 are fully uploaded to S3 buckets (ref: sns-worker: Upload computed 128-PBS ciphertexts to a S3 bucket #367)
4. Once uploaded, SnS worker notifies transaction sender ( NOTIFY add_ciphertexts )
5. Transaction sender receives notification and fetches all tuples (handle, ciphertext_digest, ciphertext128_digest, key_id)

SELECT handle, ciphertext128, ciphertext
            FROM ciphertexts_digest
            WHERE is_sent = false 
            AND ciphertext128 IS NOT NULL
            AND ciphertext IS NOT NULL
            AND retry_count < $1

NB: New table ciphertexts_digest should be introduced.

6. Transaction sender creates and executes a transaction for each ciphertext tuple (handle, digest_1, digest_2)
7. If transaction fails, a retry-send mechanism should be in place
8. If transaction succeeds, IS_SENT field to be marked as true

References

• https://github.com/zama-ai/planning-blockchain/issues/484
• ABI add_ciphertexts https://github.com/zama-ai/fhevm-backend/blob/main/fhevm-engine/transaction-sender/contracts/CiphertextStorage.sol

Unknowns

• How to initialize key_id . Can we use chain_id for now?

[dartdart26]

Flow looks good to me!

Re key ID, maybe we can hardcode it for now and deal with it possibly changing later on copro side?