Adopt cryptobyte's updated ReadOptionalASN1Boolean

[aarongable]

Version 0.17.0 of the golang.org/x/crypto/cryptobyte/asn1 package contains https://go-review.googlesource.com/c/crypto/+/274242, which fixes golang/go#43019. This should enable us to use this library method instead of using our own custom lints.ReadOptionalASN1BooleanWithTag.

[aarongable]

Ah. This doesn't work because cryptobytes ReadOptionalASN1Boolean method only works on explicitly tagged optional booleans. It even says this (although its easy to miss) in the documentation (emphasis added):

ReadOptionalASN1Boolean attempts to read an optional ASN.1 BOOLEAN explicitly tagged with tag into out and advances

This means that it expects

onlyContainsUserCerts  [1]  BOOLEAN DEFAULT FALSE,

with value "true" to be encoded as

81 03 01 01 FF

that is: context-specific tag 1 with length 3, explicitly wrapping global tag 1 (boolean) with length 1, and value TRUE.

But the IssuingDistributionPoint extension expects implicit encoding. Where its defined in both X.509 itself and in RFC 5280, it's in an ASN.1 module that sets DEFINITIONS IMPLICIT TAGS, so all optional (or default) fields are expected to be encoded implicitly unless stated otherwise. The definition of IssuingDistributionPoint doesn't state otherwise.

This means that ReadOptionalASN1Boolean expects the inner value of the context-specific tag to be three bytes (another tag, length, value triplet), but it's actually only one byte (just the value from the implicit tag it already unwrapped), and so it reports that "the read was unsuccessful" (i.e. it returns false).

I'm going to close this PR. We can't simply use this nicely-updated library method. I think the action items from here are:

1. Consider renaming our "ReadOptionalASN1BooleanWithTag" to "ReadImplicitOptionalASN1Boolean", since the implicit/explicit distinction is now more salient that the "with tag" distinction.
2. File a bug against cryptobyte to consider exposing Implicit versions of these read functions.