[release/7.0] Fix native memory leak on OCSP_Response

[github-actions]

Backport of #96561 to release/7.0-staging.
Fixes #96616.

/cc @rzikm

Customer Impact

Regression: Yes, after upgrade to .NET 7 or .NET 8, OCSP stapling is new by-default enabled feature (introduced by #67011) which introduced also the memory leak, if the app uses the “right” APIs and server supports OCSP.
Customer impact: 5 independent reports in last 6 months. Hard to diagnose issue (took at least 1 engineering month just to root cause)

• Azure SignalR -- validated on 7.0 privates and confirmed the problem is addressed
• +1 internal team hitting similar problem (no verification) during migration .NET 6 -> 8
• 2 reports on GH in Large unmanaged memory growth (leak?) when upgrading from .NET 6 to 8 #95922 (comment) during migration .NET 6 -> 8 ...1 customer validated on private 8.0 bits
• 1 report on GH in How to debug memory leak that is not clear on dotnet-dump? diagnostics#4139 (comment) with support request associated on .NET 7

Slow native memory leak under specific feature conditions (see below) leading to increased memory footprint and later application crash. Impacts service availability.

Affected scenario is a specific subset of client authentication during TLS connection:

• Server sends OCSP staple during TLS handshake (.NET 7+, or other stacks supporting OCSP)
• A client certificate is used and supplied via LocalCertificateSelectionCallback to SslStream:
  • This is the default behavior for HttpClientHandler (default handler for HttpClient)
  • Alternative ways do not have the problem (SslClientAuthenticationOptions.ClientCertificatesCollection or SslClientAuthenticationOptions.ClientCertificateContext)
• Server performs renegotiation (or post-handshake client authentication)

Testing

Tested on a small application which reproduced the memory leak. The leak is gone after this change.
Customer validation:

• Azure SignalR validated the problem is addressed on private 7.0 bits.
• .NET 8 private bits verified by GH reporter in Large unmanaged memory growth (leak?) when upgrading from .NET 6 to 8 #95922 (comment)

Risk

Low, one-line change.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #96561 to release/7.0-staging

/cc @rzikm

Customer Impact

Testing

Risk

IMPORTANT: If this backport is for a servicing release, please verify that:

• The PR target branch is release/X.0-staging, not release/X.0.

• If the change touches code that ships in a NuGet package, you have added the necessary package authoring and gotten it explicitly reviewed.

Author:	github-actions[bot]
Assignees:	-
Labels:	area-System.Security
Milestone:	-

[carlossanlop]

@rzkim - Friendly reminder that Tuesday January 16th 4pm is the Code Complete deadline for the February Release. If all requirements are met, please merge your PR before that date and time to ensure this fix gets included in that Release.

[karelz]

Approved by Tactics (@SteveMCarroll) on 1/15 via email - label updated to Servicing-approved.

[rzikm]

CI failure is unrelated (wasm)