improve SslStream tests on misconfigured systems

[wfurt]

fixes #64943
I did not any real hangs. But since LOT of tests failing, the run takes very long time ~ 17 minutes on my repro machine.

The most problematic are tests expecting failures. However since we fail to even send something in many cases we basically wait 4 minutes for each failing test.

This change has two parts:
When we expect failure, ignore only Authentication exceptions. That will raise Win32Exception and fail the test in cases we even fail so send something.

It drops PassingTestTimeoutMilliseconds to 1 minute. Since we generally use it to time box single SSL it is still plenty but still much less than original value.

With this failed runs takes ~ 7 minutes and it should finish in CI.

Better platform detection and failure avoidance comes from #64923.

cc: @safern we should take this to 6.0 if we ever back-port the 2022 queue.

[ghost]

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

Issue Details

---

fixes #64943
I did not any real hangs. But since LOT of tests failing, the run takes very long time ~ 17 minutes on my repro machine.

The most problematic are tests expecting failures. However since we fail to even send something in many cases we basically wait 4 minutes for each failing test.

This change has two parts:
When we expect failure, ignore only Authentication exceptions. That will raise Win32Exception and fail the test in cases we even fail so send something.

It drops PassingTestTimeoutMilliseconds to 1 minute. Since we generally use it to time box single SSL it is still plenty but still much less than original value.

With this failed runs takes ~ 7 minutes and it should finish in CI.

Better platform detection and failure avoidance comes from #64923.

cc: @safern we should take this to 6.0 if we ever back-port the 2022 queue.

Author:	wfurt
Assignees:	wfurt
Labels:	area-System.Net.Security, test enhancement
Milestone:	-

[wfurt]

Failing macOS tests are #64963

[CarnaViire]

LGTM

[safern]

cc: @safern we should take this to 6.0 if we ever back-port the 2022 queue.

We already did. So maybe we should get the backport going.

[safern]

/backport to release/6.0

[github-actions]

Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/1814810434

[wfurt]

sounds good @safern. There is more. I'll initiate the backports as they get into main to stabilize the S2022 runs.

[wfurt]

all the test failures looks like infrastructure issues.