feat: Ability to limit request size and connection count

[djones6]

Description

This PR implements a requestSizeLimit (maximum bytes for a request, including the headers) and connectionLimit on total number of concurrent connections.

This is exposed through a new API in Kitura for the user to set these options upon registering a server: Kitura/Kitura#1481

Example usage from Kitura is as follows:

let options = ServerOptions(requestSizeLimit: 100, connectionLimit: 3)
Kitura.addHTTPServer(onPort: port, with: router, options: options)

If you do not specify either of the parameters, or do not specify a ServerOptions at all, then default values are used. The defaults are defined as constants ServerOptions.defaultRequestSizeLimit and ServerOptions.defaultConnectionLimit.

• I didn't think too long about these defaults. They can be set to whatever we agree is a sensible value, though I'd avoid setting them too low, as we would potentially break existing deployments.

If a client sends a request that exceeds the limit, then they are immediately sent an HTTP/1.1 413 Request Entity Too Large and the connection is closed.
If a client attempts to connect, but we are already at the connection limit, they are immediately sent an HTTP/1.1 503 Service Unavailable and the connection is closed.

These responses can be further customized by supplying requestSizeResponseGenerator and connectionResponseGenerator closures, which are passed an Int (the limit that was exceeded) and a String (the hostname and port of the socket), and return an HTTPStatusCode and a String that is a plaintext message to be returned to the client. The default responses are again defined as constants defaultRequestSizeResponseGenerator and defaultConnectionResponseGenerator.

Some issues I'm aware of:

• There are already parameters keepAlive and allowPortReuse on Kitura.addHTTPServer which could be rolled into this new options struct.
• The policing of the read limit is inexact: we read as many bytes as are provided to us in the next read operation, and if that causes us to exceed the read buffer limit, we then fail. In most real-world scenarios, I'd expect that data will arrive in small enough buffers for this not to matter.

Motivation and Context

See: Kitura/Kitura#1384

How Has This Been Tested?

Tests have been added as part of Kitura/Kitura#1481

Checklist:

• I have submitted a CLA form
• If applicable, I have updated the documentation accordingly.
• If applicable, I have added tests to cover my changes.

[ianpartridge]

Good stuff, thanks!