Convert Https connection adapter to connection middleware

[davidfowl]

As part of bedrock, connection adapters are going away and we should port the tls connection adapter to middleware. We don't want to break the public API of the existing extension method on ListenOptions so that will remain.

The true TLS implementation should be in Microsoft.AspNetCore.Protocols.Tls and Kestrel.Tls should delegate to it in the implementation.

Edit: Also convert Logging connection adapter to middleware.

[muratg]

Related: aspnet/KestrelHttpServer#1665

[muratg]

@davidfowl assigning to you as the other Connection Adapter bug is also assigned to you.

[muratg]

@davidfowl I believe you're working on this currently.

[muratg]

(Please see the edit above)

[davidfowl]

I'm going to take another stab at this.

[analogrelay]

Milestone: @davidfowl (aka never whenever he gets to it)

[davidfowl]

Old version aspnet/KestrelHttpServer#2849

[jkotalik]

@davidfowl should we add this to #10869?

[davidfowl]

Sure.

[fubar-coder]

My use case is a little more complicated, because I wanted to implement AUTH TLS for an FTP server. This stuff is quite crazy, as I have to do the following:

• Have a connection middleware that works in a "pass-through" mode by default
• Stop the receiving task without disposing anything (effectively pausing it)
• Send a response that the connection switches to SslStream
• Flush and stop the sending task without disposing anything (effectively pausing it)
• Do an SslStream.AuthenticateAsServer
• Start the sending task which now uses the SslStream
• Start the receiving task which now uses the SslStream

The other way (from SslStream to pass-through) needs to work too (REIN command).

[davidfowl]

This is done. I'll file another issue for exposing a pure TLS middleware, we did the bare minimum to migrate Kestrel's HTTPS IConnectionAdapter to middleware, it'll likely be identical to the TLS middleware (we'll build it on top).