Consider adding metrics for causes of Unauthorized OCSP responses

[jcjones]

Unauthorized can come from a variety of possibilities; we should emit metrics that break down the internal cases, so we can tell if a request appears to be legitimate* but no response is available, vs one that is not for our issuers, vs one that is for an expired certificate.

• Legitimate in this case would might require additional lookups at the SA (does this Certificate/Precertificate/Serial exist?), and thus we might not want to suffer the cost, but we should investigate.

[aarongable]

We have three of these metrics already:

• If we don't find the cert status in the db: https://github.com/letsencrypt/boulder/blob/b5b5033136427c988e20ca11f1f7471563f90616/ocsp/responder/db_source.go#L50-L55
• If the cert is expired: https://github.com/letsencrypt/boulder/blob/b5b5033136427c988e20ca11f1f7471563f90616/ocsp/responder/db_source.go#L62-L65
• If the cert has a status row but the ocsp status itself has never been updated: https://github.com/letsencrypt/boulder/blob/b5b5033136427c988e20ca11f1f7471563f90616/ocsp/responder/db_source.go#L66-L69

We're missing some others:

• If we don't support the request's hash algorithm: https://github.com/letsencrypt/boulder/blob/b5b5033136427c988e20ca11f1f7471563f90616/ocsp/responder/filter_source.go#L97-L98
• If we don't recognize the serial prefix: https://github.com/letsencrypt/boulder/blob/b5b5033136427c988e20ca11f1f7471563f90616/ocsp/responder/filter_source.go#L110-L111
• If we don't recognize the request's issuer key hash: https://github.com/letsencrypt/boulder/blob/b5b5033136427c988e20ca11f1f7471563f90616/ocsp/responder/filter_source.go#L120

Those are all the places we return ErrNotFound, which is what gets converted into "Unauthorized" right before being returned to the client.