fix: return 421 for SNI and Host mismatches on mTLS requests - #14013

Description

HTTP/2 clients can reuse a TLS connection established for origin A to send requests to origin B when both origins share an endpoint and the server certificate covers both.

When B requires mTLS and the request Host differs from the connection's SNI, APISIX currently returns 400. On vanilla OpenResty, a missing client certificate can cause this rejection before the SNI mismatch check.

Return 421 Misdirected Request for the existing SNI/Host mismatch restriction, so clients can retry using a new connection with the target origin's SNI and provide its required client certificate.

Changes

• Move the target mTLS SNI/Host mismatch check before the client certificate verification-result check.
• Return false, 421 for this mismatch.
• Use core.response.exit(status or 400) at the call site, preserving 400 for other verification failures.
• Update affected mTLS tests for both OpenResty variants.

The existing restriction remains: mismatched SNI and Host are rejected even if both origins share the same mTLS configuration. No new SSL configuration is required.

Which issue(s) this PR fixes:

Fixes #14008

Verification

• Six function-level cases passed against the modified function.
• Eight actual HTTP/2 integration cases passed using APISIX 3.17.0 with the modified function and call site.
• Linux Chromium reused A's connection for B, received 421, automatically retried with SNI=B, presented a valid client certificate, and received 200.
• The same browser retry without a client certificate failed authentication.
• Integration checks covered missing certificates, incorrect certificate purpose, skipped/protected mTLS paths, and mismatched SNI/Host.
• git diff --check passed.

The full repository Test::Nginx suite has not been run. The browser test used no-cors and did not verify JavaScript access to a business API response. This draft is for initial review.

Checklist

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change (updated existing cases)
• I have updated the documentation to reflect this change
• I have verified that this change is backward compatible

Compatibility note: requests rejected for this mismatch now receive 421 instead of 400. Other verification failures retain their existing behavior.