avoid some allocations during TLS handshake

[wfurt]

this is follow-up #87874 and it contributes to #68951

The trivial change is SslStreamPal.Windows.cs. Somehow during the re-factoring I failed to notice that the flag is not set true by default any longer as it was when I started ;(
I found that when running final tests @davidfowl asked me to.

While running that I also found one more opportunity: When we query RemoteCertificate we always create safe handle and if there is no certificate (common for servers) then we set the handle to Invalid. This change shuffles the PAL code a little bit so we allocate SafeFreeCertContext only if there is certificate to wrap.

With that the allocations looks like this for 100 rounds on server:

[ghost]

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

Issue Details

---

this is follow-up #87874 and it contributes to #68951

The trivial change is SslStreamPal.Windows.cs. Somehow during the re-factoring I failed to notice that the flag is not set true by default any longer as it was when I started ;(
I found that when running final tests @davidfowl asked me to.

While running that I also found one more opportunity: When we query RemoteCertificate we always create safe handle and if there is no certificate (common for servers) then we set the handle to Invalid. This change shuffles the PAL code a little bit so we allocate SafeFreeCertContext only if there is certificate to wrap.

With that the allocations looks like this for 100 rounds on server:

Author:	wfurt
Assignees:	wfurt
Labels:	area-System.Net.Security
Milestone:	9.0.0

[rzikm]

LGTM