[release/5.0] Fix Socket.ReceiveFrom regression on Unix

[antonfirsov]

Backport of #46151 to release/5.0

Fixes: #45651

Customer Impact

Reported by customer.
On Unix, when using blocking overloads of Socket.ReceiveFrom (typically used in UDP scenarios) after an asynchronous call to the same socket, the call may return wrong remote EndPoint (remoteEP).
A DNS server project hit this incompatibility (see #46151). We expect more UDP scenarios to hit it (typically on the server-side).

Regression?

Yes. The behavior is correct on 3.1, it's a regression introduced in 5.0.

Testing

New targeted test case included in the PR.

Risk

Low. The bug was a small overlook in perf refactoring in the space during 5.0. The fix is minimal, and impacts only the affected sync-over-async ReceiveFrom path.

[ghost]

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

Issue Details

---

Backport of #46151 to release/5.0

Fixes: #45651

Customer Impact

On Unix, when using blocking overloads of Socket.ReceiveFrom after an asynchronous call to the same socket, the call may return wrong remoteEP.

Regression?

Yes. The behavior is correct on 3.1.

Testing

Extended SocketTestHelper so existing tests can validate the sync-over-async path of the blocking ReceiveFrom. Unfortunately, those tests are disabled on the 5.0 branch, so I had to port a minimal subset of #44591 (fix enabling the tests) so we can run them on CI for 5.0.

Risk

Low. The bug was a small overlook, the fix is trivial, that impacts only the affected sync-over-async ReceiveFrom path.

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

[ghost]

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

Issue Details

---

Backport of #46151 to release/5.0

Fixes: #45651

Customer Impact

On Unix, when using blocking overloads of Socket.ReceiveFrom after an asynchronous call to the same socket, the call may return wrong remoteEP. Users of the Socket type working with UDP may hit this.

Regression?

Yes. The behavior is correct on 3.1.

Testing

In the original PR I extended SocketTestHelper so our existing SendToRecvFrom_Datagram_UDP tests can validate the sync-over-async path of the blocking ReceiveFrom. Unfortunately, those tests are disabled on the 5.0 branch, so I had to port a minimal subset of #44591 (the fix enabling the tests) so we can run them on CI for 5.0.

Risk

Low. The bug was a small overlook, the product code change is minimal, and impacts only the affected sync-over-async ReceiveFrom path.

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

[antonfirsov]

Unrelated test failure is #43981.

[karelz]

@danmosemsft this is ready for 5.0 servicing ...