Improve NonDisposedSocket_SafeHandlesCollected test

[antonfirsov]

As reported in #50068, the test DisposedSocket.NonDisposedSocket_SafeHandlesCollected seems to intermittently hang the entire pipeline, although I believe it's a very rare case.

The problem is that currently there are no statistics on frequency and/or other starting points to diagnose it. This PR attempts to improve the test:

• Failure should result in a timeout not a hang, so we can get better logs and Kusto stats
• There may be two reasons: Hang in CreateHandlesAsync or hang in the finalizer. We need to be able to distinguish between those reasons.

@geoffkizer @wfurt thoughts?

[ghost]

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

Issue Details

---

As reported in #50068, the test DisposedSocket.NonDisposedSocket_SafeHandlesCollected seems to intermittently hang the entire pipeline, although I believe it's a very rare case.

The problem is that currently any statistics or other starting points to diagnose it. This PR attempts to improve the test:

• Failure should result in a timeout not a hang, so we can get logs and Kusto stats
• There may be two reasons: Hang in CreateHandlesAsync or in the finalizer. We need to be able to distinguish between those reasons.

@geoffkizer @wfurt thoughts?

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net.Sockets
Milestone:	-

[geoffkizer]

I wonder if there should be some sort of debug-only logic in the Socket finalizer to try to detect that we are hanging. Like assert after a certain # of iterations?

Regardless, this change seems worthwhile to help track down what's happening here.

[antonfirsov]

I wonder if there should be some sort of debug-only logic in the Socket finalizer to try to detect that we are hanging.

That makes sense but it should be a separate effort. Here I'm just trying to quickly bring #50068 to a somewhat better state, before someone just disables the test with a big hammer.