Run MsQuic tests in parallel.

[rzikm]

Closes #55979.

Past work in #98361 resolved the issue and all CI images have picked up microsoft/msquic#4164.

[rzikm]

/azp run runtime-coreclr libraries-outerloop

[azure-pipelines]

No pipelines are associated with this pull request.

[rzikm]

/azp run runtime libraries-coreclr-outerloop

[azure-pipelines]

No pipelines are associated with this pull request.

[rzikm]

/azp run runtime-libraries-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[rzikm]

Test failures don't seem related, all platforms seem to have recent enough MsQuic so all fixes are appled. I think we can go ahead an proceed. Please review.

[rzikm]

actually, let's look also at jitstress and other stress pipelines

[rzikm]

/azp run runtime-coreclr jitstress

[rzikm]

/azp run runtime-coreclr jitstressregs

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ManickaP]

Should we also remove this:

runtime/src/libraries/System.Net.Http/tests/StressTests/HttpStress/Program.cs

Lines 189 to 205 in b7c3446

	if (config.HttpVersion == HttpVersion.Version30 && IsQuicSupported)
	{
	unsafe
	{
	// If the system gets overloaded, MsQuic has a tendency to drop incoming connections, see https://github.com/dotnet/runtime/issues/55979.
	// So in case we're running H/3 stress test, we're using the same hack as for System.Net.Quic tests, which increases the time limit for pending operations in MsQuic thread pool.
	object msQuicApiInstance = msQuicApiType.GetProperty("Api", BindingFlags.NonPublic | BindingFlags.Static)!.GetGetMethod(true)!.Invoke(null, Array.Empty<object?>())!;
	QUIC_API_TABLE* apiTable = (QUIC_API_TABLE*)(Pointer.Unbox(msQuicApiType.GetProperty("ApiTable")!.GetGetMethod()!.Invoke(msQuicApiInstance, Array.Empty<object?>())!));
	QUIC_SETTINGS settings = default(QUIC_SETTINGS);
	settings.IsSet.MaxWorkerQueueDelayUs = 1;
	settings.MaxWorkerQueueDelayUs = 2_500_000u; // 2.5s, 10x the default
	if (MsQuic.StatusFailed(apiTable->SetParam(null, MsQuic.QUIC_PARAM_GLOBAL_SETTINGS, (uint)sizeof(QUIC_SETTINGS), (byte*)&settings)))
	{
	Console.WriteLine($"Unable to set MsQuic MaxWorkerQueueDelayUs.");
	}
	}
	}

And also all of these in H3 tests:

runtime/src/libraries/System.Net.Http/tests/FunctionalTests/SocketsHttpHandlerTest.cs

Line 4027 in b7c3446

[Collection(nameof(DisableParallelization))]

???

[rzikm]

/azp run runtime-coreclr jitstress

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[rzikm]

There's one failure of System.Net.Quic.Tests.MsQuicTests.CertificateCallbackThrowPropagates, that one is due to a bug in MsQuic which I have pending PR for, the test should actually be disabled completely. Otherwise CI looks good

[rzikm]

Ci failures are unrelated, let's roll.