This wasn't an actual issue, but the fix is equivalent.

This allows new errors to have minimal diffs.

This is executing a TODO when the chain length exceeds 6 issuers deep.

This commit renames the `check_signatures` fn, as it is doing more than
simply verifying signatures. It also checks revocation status w/ CRLs
when appropriate.

This commit updates the name constraint validation done during path
building to apply a budget for the maximum allowed number of name
constraint checks.

We use the same limit that golang crypto/x509 applies by default:
250,000 comparisons.

Note: this commit applies the budget during path building in a manner
that means certificates _not_ part of the built path can consume
comparisons from the budget even though they will not be present in the
complete validated path. Similarly name constraints are evaluated before
signatures, meaning a certificate that doesn't verify to a trusted root
still has its constraints parsed and evaluated. A subsequent commit
will adjust these shortcomings.

This commit updates the path building process such that name constraints
are only evaluated against a complete path where signatures on the chain
have been checked successfully to a trust anchor. This avoids:

* Parsing name constraints before signatures are validated.
* Evaluating name constraints and consuming name constraint comparison
  budget for certificates that are not part of the
  built path.

In the future it could be possible to interleave the name constraint
checking with the signature checking, however the logic for this is more
complicated. For an initial fix let's prefer a simpler solution that
walks the built + validated path to check name constraints from the
trust anchor to the end entity certificate.

This commit adds a pair of tests reproducing issue rustls#167,
where the `EndEntityCert::dns_names()` method returns an error
incorrectly on some certificate DER encodings. In particular,
`dns_names` fails if the CN is a `PrintableString`, or if it's an empty
`SEQUENCE`, rather than a `SEQUENCE` containing an empty `SET`.

The test for the `PrintableString` common name uses an end-entity
certificate generated using `rcgen`, while the test for empty `SEQUENCE`
CN required a hand-crafted DER using `ascii2der`. The text file that
generated the `ascii2der` cert is also included.

As suggested by @ctz in this comment:
rustls#167 (comment).

This commit removes parsing of the subject common name field from
`NameIterator`, since `rustls-webpki` does not actually verify subject
common names except when enforcing name constraints. This fixes issues
with common names in formats that `rustls-webpki` doesn't currently
support, by removing this code entirely.

Fixes rustls-webpki/webpki#167

This commit adjusts the arguments to the `verify_chain` test helper to
take references instead of moving the arguments. This makes it easier to
use the same inputs for multiple `verify_chain` invocations.

This commit updates the `verify_chain` helper to allow providing an
optional `Budget` argument (using the default if not provided). This
makes it easier to write tests that need to customize the path building
budget (e.g. `name_constraint_budget`).

This commit adds a method to `Error` for testing whether an error should
be considered fatal, e.g. should stop any further path building
progress. The existing consideration of fatal errors in
`loop_while_non_fatal_error` is updated to use the `is_fatal` fn.

Having this in a central place means we can avoid duplicating the match
arms in multiple places, where they are likely to fall out-of-sync.

Previously the handling of fatal path building errors (e.g. those that
should halt all further exploration of the path space) was mishandled
such that we could hit the maximum signature budget and still pursue
additional path building. This was demonstrated by the
`test_too_many_path_calls` unit test which was hitting
a `MaximumSignatureChecksExceeded` error, but yet proceeding until
hitting a `MaximumPathBuildCallsExceeded` error.

This commit updates the error handling between the first and second
`loop_while_non_fatal_error` calls to properly terminate the search when
a fatal error is encountered, instead of proceeding with further search.

The existing `test_too_many_path_calls` test is updated to use an
artificially large signature check budget so that we can focus on testing
the limit we care about for that test without needing to invest in
more complicated test case generation. This avoids hitting
a `MaximumSignatureChecksExceeded` error early in the test (which now
terminates further path building), instead allowing execution to
continue until the maximum path building call budget is expended
(matching the previous behaviour and intent of the original test).

The `loop_while_non_fatal_error` helper can return one of three things:

* success, when a validated chain to a trust anchor was built.
* a fatal error, e.g. when a `Budget` has been exceeded and no further
  path building should occur because we've exhausted a budget.
* a non-fatal error, when a candidate chain results in an error
  condition, but other paths could be considered if the options are not
  exhausted.

This commit attempts to express this in the type system, centralizing
a check for what is/isn't a fatal error and ensuring that downstream
callers to `loop_while_non_fatal_error` handle the fatal case
appropriately.