Disable MsQuicTests.CertificateCallbackThrowPropagates test

[rzikm]

Contributes to #99074.

Seems like microsoft/msquic#4145 was not enough to fix async certificate rejection.

The test spuriously fails on platforms which have MsQuic built from main, which seems to be the Alpine queues where we don't have MsQuic release feeds for.

[ghost]

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

Issue Details

---

Contributes to 99074.

Seems like microsoft/msquic#4145 was not enough to fix async certificate rejection.

The test is spuriously fails on platforms which have MsQuic built from main, which seems to be the Alpine queues where we don't have MsQuic release feeds for.

Author:	rzikm
Assignees:	rzikm
Labels:	area-System.Net.Quic
Milestone:	-

[CarnaViire]

MsQuic built from main

IIRC it would have the version number of the last release +1, would the version comparison actually work? Should we just disable it for Alpine?

[rzikm]

IIRC it would have the version number of the last release +1, would the version comparison actually work? Should we just disable it for Alpine?

That's true, but the issue is not Alpine specific, it happens when we try to do the certificate validation asynchronously. There were actually two bugs in MsQuic:

• It would attempt to send Transport Close on 1RTT, this I have fixed in main, and I have added a version check to .NET code so that we would do the validation asynchronously only if we run against MsQuic with the fix, which is currently in only main, so the check is >= 2.4.
• There is a race between ConnectionCertificateValidationComplete and ConnectionShutdown which is more rare and I did not hit it during testing, but it semi-reliably hits on Alpine containers, more info on the original issue.

So, on versions < 2.4 we will do the validation inline and will avoid both of the above mentioned issues.

[rzikm]

CI failures are unrelated