Today the transport is responsible for exposing properties on the connection that can be used by Kestrel to create a duplex pipe. It does this today for a few reasons:

• It wants to directly apply the MaxResponseBufferSize and MaxRequestBuffer size to pipe options
• It communicates "fin" via cancelling the transport's output reader (this is super hacky and we should get rid of it anyways).
• It wants to control where "user code" runs. This includes:
  • ConnectionAdapters (soon to be deprecated)
  • CancellationToken callbacks
  • the request processing delegate

Delegating to the transport has some other benefits:

• Transports aren't tied to a specific pipe implementation.
• We can potentially delete ITransportSchedulerFeature, IApplicationTransportFeature

To make this change though, we need to pass the relevant settings from kestrel to the transport without coupling. My current though is to pass a settings object to ITransportFactory.Create.

See https://github.com/geoffkizer/KestrelHttpServer/blob/7bd21cdb1581fc3559479842262a24deecf171bb/src/Kestrel.Transport.Sockets/Internal/SocketConnection.cs for an example of the socket transport with a direct pipe implementation.

/cc @tmds @benaadams (only other people that wrote transports 😄)