HTTP/3 fixed some tests

[ManickaP]

Some HTTP/3 tests fail when ran with msquic. This is an attempt to fix some of them.
Also removed H/3 from versioning tests since we cannot do upgrades/downgrades with HTTP/3 over the same connection (TCP vs UDP). And we already have tests for Alt-Svc upgrade.

[ghost]

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

Issue Details

---

Some HTTP/3 tests fail when ran with msquic. This is an attempt to fix some of them.

Author:	ManickaP
Assignees:	-
Labels:	area-System.Net.Http
Milestone:	-

[ManickaP]

@wfurt I don't know if this change is what we want/need. but it did help with some of the failing tests.

[wfurt]

I don't think it really matters. CI may be set up to trust your contoso chain but not self-signed. Either one should be fine once we have custom validation in place.

[CarnaViire]

If we want to have a fair no-op, we should check that flags are the same as they were the last time... or at least check IsCompletedSuccessfully instead of IsCompleted - otherwise we would not be able to send an abortive shutdown after we timeouted waiting for graceful shutdown to complete (though, I'm not 100% sure msquic supports it 😬)

[ManickaP]

You're right, this is very shortsighted change. I'll just leave out the assert and handle the multiple calls to ShutdownAsync on the Http3Connection side.

[CarnaViire]

Would it be better to make a second Abort a no-op? I see the same pattern down below in ProcessServerStreamAsync -- is possibly exists in other places as well:

try
{ ... }
catch (Exception ex)
{
    Abort(ex);
}

so it may be better to treat it inside Abort?

[ManickaP]

This doesn't come from an abort though, this is a reaction to a normal shutdown initiated by us. The QuicOperationAbortedException here is thrown by the connection as reaction to AcceptQueue being closed:

runtime/src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicConnection.cs

Lines 277 to 288 in 65bcece

	try
	{
	stream = await _state.AcceptQueue.Reader.ReadAsync(cancellationToken).ConfigureAwait(false);
	}
	catch (ChannelClosedException)
	{
	throw _state.AbortErrorCode switch
	{
	-1 => new QuicOperationAbortedException(), // Shutdown initiated by us.
	long err => new QuicConnectionAbortedException(err) // Shutdown initiated by peer.
	};
	}

The code you're referencing is handling QuicOperationAbortedException caused by a different action:

runtime/src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicStream.cs

Lines 270 to 276 in 65bcece

	else if (_state.ReadState == ReadState.Aborted)
	{
	throw _state.ReadErrorCode switch
	{
	-1 => new QuicOperationAbortedException(),
	long err => new QuicStreamAbortedException(err)
	};

So, I don't think combining them is a correct solution here.

I do concur that the utilization of QuicOperationAbortedException to notify the user that the connection won't provide any more stream from AcceptStreamAsync might be questionable here. But that's not a goal of this PR, I'm just trying to make it work.

[CarnaViire]

LGTM, thanks! Would still wait for @wfurt reply on certs though...

[wfurt]

LGTM