Consider backdating certs to round hours

[aarongable]

Currently, when we issue certificates, we issue them with a notBefore date exactly 1 hour prior to the current second. This is to reduce the risk that newly-issued certificates aren't trusted because a client connecting to their server has a slightly-skewed clock. The BRs allow for backdating Subscriber certificates up to 48 hours for this purpose.

Separately, we're becoming more aware that having database tables with indices on datetime columns is very inefficient. The size of an index is determined by the number of unique values in the indexed columns, and continuous values like timestamps produce very large indices. It would be nice if our timestamps were (say) truncated to the hour, to significantly reduce the number of possible values they can take.

We issue significantly more than one certificate per second, so we're already saturating the leaves of an index that branches down to the level of 1 second. If we sell all of our notBefore/notAfter timestamps to fall on hour boundaries, we'd reduce the size of these indices by a factor of 3600.

So we should consider, instead of backdating our certificates by exactly one hour, backdated them by anywhere between 1 and 2 hours, to a round hour which falls in that span. In practice, this would look like notBefore = ra.clk.Now().Add(-1 * time.Hour).Truncate(time.Hour).

[aarongable]

Plan:

• Try to predict how big a traffic spike we might expect, if certs are quantized to hours
• Add fuzzing to ARI, to offset the impact of quantized certs on ARI suggested windows
• Pick a random minute (23!) and add a feature flag to quantize notBefore/notAfter to that minute of the previous hour
• Turn the feature flag on for a week
• Wait ~60 days to see if it had a meaningful impact on issuance spikes
• Go/No-go on whether to turn it on permanently

[aarongable]

@jsha now has a WIP to round all timestamps to the second in #5437; we're not planning to continue forward with this approach.