crl-storer: check number before uploading

[aarongable]

Have the crl-storer download the previous CRL from S3, parse it, and compare its number against the about-to-be-uploaded CRL. This is not an atomic operation, so it is not a 100% guarantee, but it is still a useful safety check to prevent accidentally uploading CRL shards whose CRL Numbers are not strictly increasing.

Part of #6456
DO NOT MERGE until IN-9559 is resolved

[pgporada]

There's s3 object locking which on the surface seems like an interesting way to make this action atomic, but alas

Object Lock works only in versioned buckets, and retention periods and legal holds apply to individual object versions.
Placing a retention period or legal hold on an object protects only the version specified in the request. It doesn't prevent new versions of the object from being created.

[jsha]

This looks good. Have you filed a ticket to get the appropriate permissions (get) added to the crl-storeer's IAM role in AWS? We should make sure that's finished before we merge, otherwise this will fail on deploy.

[aarongable]

Good point, thank you for the reminder! I'd forgotten that we moved from a world-readable to behind-cloudfront model. I've filed IN-9559 for this.

[aarongable]

IN-9559 has confirmed that the crl-storer does have Read access to the storage bucket. I'm cleaning up merge conflicts and then sending for re-review.

[jsha]

Looks good with one small nit.