Test coverage for the SSLVerifyClient accepted-errors argument (#632)

[notroj]

Adds test/modules/ssl/test_002_verify_client.py covering the second SSLVerifyClient argument proposed in #632, together with that PR's functional commit so the new cases have something to run against. Only the third commit of #632 is carried here: its first two reverse each other exactly, and dropping both leaves an identical tree.

Six client credentials, each built to raise one specific verification error: unknown issuer (leaf only, and leaf plus its root), self-signed, expired, not-yet-valid, and serverAuth-only EKU. The cases cover plain require rejecting all of them, optional_no_ca waiving exactly its documented set, each accepted-errors token waiving its own error and no other, comma-separated lists, and both configuration errors being rejected at startup. optional_no_ca is unchanged by #632: the regression reported in #632 (comment) does not reproduce on trunk.

One thing the coverage turned up: no single token reproduces optional_no_ca. A certificate from an unknown CA raises several errors as the chain is walked, so require untrusted-cert rejects it while require self-signed,untrusted-cert,invalid-signature accepts it. Whether the error is 20 (unable to get local issuer certificate) or 21 (unable to verify the first certificate) also depends on whether the client sends its issuer alongside the leaf, and those two codes sit under different tokens. Worth either documenting the combination or giving untrusted-cert the whole unknown-issuer set.

🤖 Generated with Claude Code