Refactor NIOHTTPServerConfiguration

[aryan-25]

Motivation:

Currently, NIOHTTPServerConfiguration's transportSecurity property implicitly determines the HTTP versions served by NIOHTTPServer:

• If transportSecurity is .plaintext, an HTTP/1.1 channel handler (over plaintext) is set up.
• If transportSecurity is .tls or .mTLS (or their certificate-reloading variants), an ALPN channel handler configured with both HTTP/1.1 and HTTP/2 handlers is set up.

As a consequence of this tight coupling, it is currently not possible to configure the server to only serve HTTP/1.1 over TLS.

Modifications:

• Added a new supportedHTTPVersions field (Set<HTTPVersion>) to NIOHTTPServerConfiguration. This, along with the transportSecurity value, allows for the following configurations to be represented:

  transportSecurity	supportedHTTPVersions	Result
  .plaintext	[.http1_1]	HTTP/1.1 over plaintext
  .tls / .mTLS	[.http1_1]	HTTP/1.1 over (m)TLS
  .tls / .mTLS	[.http2(...)]	HTTP/2 over (m)TLS
  .tls / .mTLS	[.http1_1, .http2(...)]	HTTP/1.1 or HTTP/2 over (m)TLS, negotiated via ALPN.

• Simplified TransportSecurity to three options (plaintext, tls, mTLS):

  • TLS credentials (certificate chain and private key) are nested inside the tls and mTLS cases in a TLSCredentials type which has inMemory, reloading, and pemFile backings.
  • Similarly, mTLS trust configuration is represented through a new MTLSTrustConfiguration type which has systemDefaults, inMemory, pemFile, and customCertificateVerificationCallback backings.

• Updated NIOHTTPServer based on the changes to the configuration type.

• Updated the swift-configuration integration to reflect the new structure.

Result:

The HTTP versions supported by NIOHTTPServer can now be configured explicitly through the supportedHTTPVersions property on NIOHTTPServerConfiguration, rather than being implicitly determined by the transport security configuration.

[FranzBusch]

One configuration that this (and the current) configuration don't allow is to configure a single server with HTTP/1 over plaintext and then HTTP/2 over TLS for example. Not sure if we need to support it but might be worth thinking about if we need to allow a per-connection configuration somehow.