Introduce new stream and multiplexed bedrock types

[jkotalik]

Fixes #17037.

Implements the following:

public class MultiplexedConnectionContext : ConnectionContext
{
    ValueTask<StreamConnectionContext> AcceptAsync(CancellationToken token = default);
    ValueTask<StreamConnectionContext> ConnectAsync(IFeatureCollection features = null, bool unidirectional = false, CancellationToken token = default);
}
public class StreamConnectionContext : ConnectionContext
{
    long StreamId { get; } // ConnectionId is a string today, StreamId for HTTP/3 needs to be a long, figure out how to consolidate.
    Direction Direction{ get; }
}
public enum Direction
{
   BidirectionalInbound,
   BidirectionalOutbound,
   UnidirectionalInbound,
   UnidirectionalOutbound
}
public class IConnectionFactory
{
   ValueTask<ConnectionContext> ConnectAsync(Endpoint endpoint, IFeatureCollection features = null, CancellationToken token = default);
}

A majority of this right now is generated code, which probably can be improved. Right now, the generated code needs to be a separate class per context type (Multiplexed, Stream, and Connection) because each of the Transport classes derive from those. For example:

internal abstract partial class TransportMultiplexedConnection : MultiplexedConnectionContext

[jkotalik]

@davidfowl @anurse @halter73 thoughts?

[jkotalik]

I spent the last few hours trying to update this PR to "split the world". Going to take a small break because it honestly was a lot to juggle here and I need to take a fresh look. Few open questions:

• How much value is there to duplicate HttpConnection and HttpConnectionContext. Right now, I put both the MultiplexedConnectionContext and ConnectionContext there, but there may be value in doing the protocol selection inside of the middleware rather than the HttpConnection class.
• We talked about potentially have a base class for MultiplexedConnectionContext and ConnectionContext. Ex the ConnectionLimiterMiddleware may be something to share.
• There is still a lot of work to do with the ConnectionDispatcher and KestrelServer.

[analogrelay]

Poke @jkotalik

[davidfowl]

cc @scalablecory

[jkotalik]

Alright, this PR got a little large, so let me break it down into pieces.

This PR consists of:

• Adding interfaces IMultiplexedConnectionListener, IMultiplexedConnectionBuilder, IMultiplexedConnectionFactory, and IMultiplexedConnectionListenerFactory for multiplexed connections/streams
• Add StreamContext which derives from ConnectionContext and MultiplexedConnectionContext.
• Adapts HTTP/3 to use the new multiplexed factory. This includes adding Http3(Stream/Connection)Context, a MultiplexedConnectionManager, MultiplexedKestrelConnection, etc. Some of these types are very similar to each other; I think I can still refactor this to use a new base class between ConnectionContext and MultiplexedConnectionContext, however it's a bit tricky.
• Adds a bunch of HTTP/3 tests (most of these are unrelated, but mostly for sanity checking).
• Fixing a few various bugs, mostly copying/porting from HTTP/2.
• Allows stream/connection to set protocol error code on underlying quic stream/connection.

[jkotalik]

I didn't know if we wanted these to be on the StreamContext yet.

[halter73]

I don't think StreamContext is different enough from ConnectionContext to justify its existence. Maybe this could be added to ConnectionContext with both defaulting to true, but as with StreamId, I'm not sure it's useful enough deserve be a top level property on ConnectionContext.

[SteveSandersonMS]

@jkotalik Is the change to blazor.server.js intentional? I'm guessing not since no .ts files were changed. If unintentional, could you revert that file? Thanks!

[davidfowl]

Feels like we're missing a shared interface between the MultiplexConnection and ConnectionContext. There should be a common type for the shared properties and methods.

[jkotalik]

Feels like we're missing a shared interface between the MultiplexConnection and ConnectionContext. There should be a common type for the shared properties and methods.

I mentioned that in my comment above. Probably; I need to mess around with the generate code to see what I can do.

[jkotalik]

I was chatting with @halter73 yesterday, and he mentioned that we may want to consider making the multiplexed factory internal for now due to potential refactoring in how bedrock would work.

If we were to make a base class for ConnectionContext, it would need to be public no matter what. I don't think it's a big deal, just something to note.

[jkotalik]

🆙 📅 based on discussion yesterday.

[halter73]

We need to figure out how and when we're going to internalize this. Can you create an issue @jkotalik?

[jkotalik]

Created the above issue.