Android verifier doesn't consider supplied date for revocation or intermediate roots

Today in the Android verifier, we only check the end-entity's validity against the timestamp provided by rustls. The revocation status and intermediate CA's validity uses the system's current timestamp. While this doesn't result in any security issues, it makes consistent testing harder.

To fix this, we need to use a use the setDate method of PKIXParameters. We already construct one of these for checking revocation, but we're using TrustManager.checkServerTrusted for the rest of the chain. Android's trust manager defaults to using the current date, with no way to override it here.

Modifying the logic to do everything with one verifier will be tricky, if not infeasible. This is because the Conscrypt TrustManager checks for Android-specific CA blocklisting and CT/pinning requirements, and we definitely want to keep that functionality so Android matches what Apple and Windows are doing. As is, I'm not sure how to solve the intermediate time period problem. Even if we tried doing two validations with each API set, we most likely wouldn't (unless the system already knew about every intermediate and root) see any blocklist errors because Conscrypt checks validity early. From reading through the implementation, my conclusion is that while including intermediates provided by the server an expired one would fail early before it had a chance to check it against the blocklist :( To fully resolve this, and get the best of what the platform has to offer we really need the ability to pass a timestamp into checkServerTrusted.

With all that said, a partial and feasible fix is to just start setting the datetime for our revocation checks and use the fact intermediates don't expire often to hopefully treat this a non-issue in practice.

Start in android/rustls-platform-verifier/src/main/java/org/rustls/platformverifier/CertificateVerifier.kt around the end-entity validity check at lines 206-213, then inspect the existing PKIXParameters construction and revocation path. Preserve Conscrypt's TrustManager checks while ensuring revocation validation uses the timestamp supplied by rustls; the issue leaves the intermediate-certificate approach unresolved.