Quic transport is no longer experimental in .NET 6

[JamesNK]

Quic transport is no longer experimental in .NET 6

This PR is a YOLO find and replace to remove Experimental from the Quic transport project and namespaces. I'd apprietate guidance on any ritutuals that are required when removing and adding packages from aspnetcore.

Two things:

1. The runtime package we depend on still has Experimental in the name: System.Net.Experimental.MsQuic.
2. I think we should consider updating the project name and namespace to Microsoft.AspNetCore.Server.Kestrel.Transport.MsQuic (note: Quic -> MsQuic). That's consistent with runtime's name. And in the future the Quic implementation might change to be written in managed code so we should be more specific.

PR

• Renames and removes Experimental from Quic transport project
• Removes Experimental from multiplex connection abstractions types

APIs promoted from experimental status need API review.

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[JamesNK]

Review notes:

IMultiplexedConnectionListenerFactory:

• BindAsync IFeatureCollection used?
• Indented for per endpoint cert?

IMultiplexedConnectionListener:

• AcceptAsync IFeatureCollection used?

MultiplexedConnectionContext:

• ValueTask<ConnectionContext> ConnectAsync, change return to nullable
• Debate about ConnectAsync name. Options:
  • OpenAsync
  • CreateAsync

QuicTransportFactory:

• Make internal. Likely was made public to match sockets transport

WebHostBuilderMsQuicExtensions:

• Rename to WebHostBuilderQuicExtensions

QuicTransportOptions:

• Revist everything

Will remove experimental now and make changes through previews. Re-review later in .NET 6.

@jkotalik @Tratcher @halter73 @davidfowl @wtgodbe

[halter73]

The IFeatureCollection arguments are intended for future extensibility. Since TLS becomes a transport concern with QUIC using it for certs sounds like a viable option.

Why does ConnectAsync need to return a nullable?

[JamesNK]

Why does ConnectAsync need to return a nullable?

@jkotalik added that feedback. Is it to make ConnectAsync return consistent with AcceptAsync?

[JamesNK]

@dougbu The CI build is failing with this message:

eng\Baseline.Designer.props(,): error : Generated code is not up to date in eng/Baseline.Designer.props. You might need to regenerate the reference assemblies or project list (see docs/ReferenceAssemblies.md and docs/ReferenceResolution.md)

What changes do I need to make to pass CI build?

[dougbu]

What changes do I need to make to pass CI build?

It's mostly not you @JamesNK (and this likely applies to every PR that targets 'main' and not-yet-verified):

1. I need to get [release/5.0] Merge, update baselines, SDK and runtimes #30781 in
2. Bot needs to create a merge PR into 'main'
3. I need to get that PR in
4. You need to rebase on latest 'main'

[JamesNK]

Ok! No urgency to get this PR in.

[jkotalik]

@jkotalik added that feedback. Is it to make ConnectAsync return consistent with AcceptAsync?

Yeah that was the idea behind it. Though maybe throwing for either if they fail to connect or accept makes more sense?

[JamesNK]

@dougbu @JunTaoLuo @wtgodbe Good to merge from a build POV?

[wtgodbe]

LGTM build-wise

[dougbu]

Side question: Why do the Baseline files appear in the final commit❔ They should have been updated as part of a merge from release/5.0.