RA: compute CRL shard upon revocation

[aarongable]

Add three new config values to the RA: crlDPBase, crlNumShards, and crlShardWidth. When a revocation request comes in, use these values to compute the CRL Shard that the revoked cert falls into, and include that shard number in the RevokeCertificate request to the SA. This will cause the SA to create a row in the revokedCertificates table, thanks to #7095.

The first new config value is used to extract the appropriate shard number from a CRL Distribution Point URL already embedded in the to-be-revoked certificate. Therefore, this value must exactly match the crlDPBase config item in the CA, which controls the CRL URLs it generates.

However, that method only works once CRLDP URLs are baked into certs, which isn't the case yet. So the second and third new config values are used to directly compute the appropriate shard based on the certificate's notAfter date, in the same way that crl-updater computes that mapping today. Therefore these values must exactly match the crl-updater's numShards and shardWidth config values.

All of the code described above only becomes active once all three new config fields are specified in the RA. This allows this change to be deployed safely, and turned on later by setting those config values.

Also update the RA's audit log for administratively-revoked certificates to include the correct revocation method name.

Part of #7094

[github-actions]

@aarongable, this PR appears to contain configuration changes. Please ensure that a corresponding deployment ticket has been filed with the new configuration values.

[jsha]

crlDPBase, crlNumShards, and crlShardWidth
...
Therefore these values must exactly match the crl-updater's numShards and shardWidth config values.

Seems like making them match might be slightly easier if RA grouped these config fields into a struct "crls" with numShards and shardWidth as fields of that struct (i.e. use the same field names as crl-updater).

[jsha]

The certificate here hasn't been validated as signed by our issuer and we haven't checked that we actually have this issuer. While the WFE has checked those properties, given that the importance of getting the crlShard right, maybe we should do it here too? Or perhaps just look up the cert in our database and verify the two are identical?

[aarongable]

I've uploaded a commit which addresses most of jsha's comments. However, I'm putting this PR back into Draft mode because we've decided that this PR will end up more elegant if we first address #7159, and then do the shard index extraction in the CA instead of in the RA.