Add swift-configuration support

[aryan-25]

Motivation:

Users should be able to initialize NIOHTTPServerConfiguration via swift-configuration.

Modifications:

Added a new initializer on NIOHTTPServerConfiguration, which has a Configuration.ConfigReader argument. This initializer populates the four child types (BindTarget, TransportSecurity, BackpressureStrategy, and HTTP2) from the reader.

Result:

Support for swift-configuration added.

[aryan-25]

For ease of reference, the table below displays the hierarchy of keys and associated information. Key names / hierarchy / type / default values are very much open for discussion.

Prefix	Configuration Key	Type	Required/Optional	Default
bindTarget	host	string	required	-
bindTarget	port	int	required	-
transportSecurity	security	string	required (permitted values: "plaintext", "tls", "reloadingTLS", "mTLS", "reloadingMTLS")	-
transportSecurity	certificateChainPEMString	string	required (for "tls" and "reloadingTLS")	-
transportSecurity	privateKeyPEMString	string	required (for "tls" and "reloadingTLS", secret)	-
transportSecurity	trustRoots	string array	optional (for "mTLS" and "reloadingMTLS")	system trust roots
transportSecurity	certificateVerificationMode	string	required (for "mTLS" and "reloadingMTLS", permitted values: "optionalVerification", "noHostnameVerification")	-
transportSecurity	certificateChainPEMPath	string	required (for "reloadingTLS" and "reloadingMTLS")	-
transportSecurity	privateKeyPEMPath	string	required (for "reloadingTLS" and "reloadingMTLS")	-
transportSecurity	refreshInterval	int	optional (for "reloadingTLS" and "reloadingMTLS")	30
backpressureStrategy	low	int	optional	2
backpressureStrategy	high	int	optional	10
http2	maxFrameSize	int	optional	2^14
http2	targetWindowSize	int	optional	2^16 - 1
http2	maxConcurrentStreams	int	optional	100

[gjcairo]

I think it may be worth adding these APIs (and the swift-configuration dependency) behind a trait, to avoid forcing this dependency on everyone.

https://docs.swift.org/swiftpm/documentation/packagemanagerdocs/packagetraits/

[gjcairo]

Style nit: I think we generally use camel case for constants. Also prefer to use inlinable computed static vars instead, for performance.

[gjcairo]

Can't we throw a more descriptive error here (and elsewhere)?

[gjcairo]

Nit, but we can have separate suites for each group of tests instead of having these marks and prefixing the test names with the group name.

[czechboy0]

I think it may be worth adding these APIs (and the swift-configuration dependency) behind a trait, to avoid forcing this dependency on everyone.

That's certainly reasonable, let's just make sure it's behind a default trait. Generally we want ecosystem API package integration to be either built-in, or behind a default trait. We shouldn't put such integrations (logs/metrics/tracing/configuration/service lifecycle) behind opt-in traits, as that'd put quite a lot of obstacles in the way of folks just getting started.