Experimental: Recycle SslStreamCertificateContext objects for client and server

[borland]

Are you a customer of Octopus Deploy? Please contact our support team so we can triage your PR, so that we can make sure it's handled appropriately.

Background

dotnet/runtime#110803 (comment)

Results

When running Halibut on .NET 9, we appear to be affected by the memory leak detailed in dotnet/runtime#110803. This says it will be fixed in .NET 10, but there is significant time until that is available.

I experimented with DOTNET_SYSTEM_NET_SECURITY_DISABLETLSRESUME=1 as a workaround, and while it helps reduce the rate of memory leaking, it does not solve it.

This PR implements the second proposed solution, which is to refactor our code to share an SslStreamCertificateContext across connections.

Note: We do not handle the SslStreamCertificateContext object directly, but rather take the second path and recycle the SslServerAuthenticationOptions object which owns the certificate context.

Also

While the github issue only describes a memory leak when dealing with a server-side stream, SslStreamCertificateContext is also employed on the client side since it was added into SslClientAuthenticationOptions in dotnet 8

If the certificate context leaks an OpenSSL handle when used for server auth, it seems reasonable that it could also leak when used for client auth. So this PR also reuses SslClientAuthenticationOptions by way of a cache, to see if that helps.

How to review this PR

Quality ✔️

Pre-requisites

• I have read How we use GitHub Issues for help deciding when and where it's appropriate to make an issue.
• I have considered informing or consulting the right people, according to the ownership map.
• I have considered appropriate testing for my change.