Right now, CertStatus is used by the CertVerifier to return all the errors it could find with the certificate. However, it's *also* used to smuggle certificate state information up to the higher layers - things like the evaluation of CT policy, or, in the case of ERR_SSL_[WEAK_SERVER_EPHEMERAL_DH_KEY/PINNED_KEY_NOT_IN_CERT_CHAIN], the underlying TLS policy independent of the certificate (per-se)

We should figure out what the conceptual layering of CertStatus should be, so that it's clearer what the recommended path forward is.

Historically, the use of CertStatus was to allow the MapNetErrorToCertStatus/MapCertStatusToNetError roundtrips, which is what allows SSL interstitial pages to show the 'right' error (namely, a "friendly" SSL error page rather than the general network error page). However, what we actually pass up from //net to the higher layers is the full SSLInfo (from URLRequestHttpJob's NotifySSLCertificateError), so there's a question about whether errors such as DH key size or pinning violations more properly belong on the SSLInfo.

Now that we have the SecurityStateModel that more properly encapsulates the settings for interstitial UI, if we move these errors from CertStatus' to SSLInfo, we'd need to correspondingly update the VisibleSecurityState/SecurityInfo classes to be able to continue propagating that information to the various UI surfaces.

On its face, this *seems* like a correct layering (namely, moving these "SSL policy" checks onto SSLInfo's communication layer), but there may be a reasonable argument for keeping them on the CertStatus to ease propagation.

If moving them to the VSS/SI, there's a question about whether we want to surface individual bools, or whether it makes more sense to have the SSLInfo propagate up the SSL error code reported by the socket.