Add ability to limit maximum number of authorized incoming connections

[APErebus]

Background

Clients can open multiple TCP connections for a single polling subscription. This has the potential to overload the halibut server (or Octopus Server). This PR adds a new value to the HalibutTimeoutsAndLimits, the MaximumActiveTcpConnectionsPerPollingSubscription. This is used to limit the number of active connections a polling subscription can have open at once.

Results

Once we have performed SSL & Thumbprint authorization of the connection, in the MessageExchangeProtocol, when we are exchanging as the server, if the remote endpoint is a subscription, then we use that subscription id to validate the number of active connections they have open.

If they exceed the defined maximum, a ActiveTcpConnectionsExceededException is thrown.

We also make sure that the polling client doesn't mark the retry policy as successfully until we have successfully exchanged identification messages with the server. This means that if the connection fails or is terminated during identification, we aren't saying it succeeded.

If the MaximumActiveTcpConnectionsPerPollingSubscription value is null (the default), then no limiting will occur.

How to review this PR

Quality :heavy_check_mark:

Pre-requisites

• [ ] I have read How we use GitHub Issues for help deciding when and where it's appropriate to make an issue.
• [x] I have considered informing or consulting the right people, according to the ownership map.
• [x] I have considered appropriate testing for my change.

[APErebus]

One thing @LukeButters and I realised while debugging failing tests is that Halibut actually tries multiple times to establish a connection before it starts backing off. This means that if a client exceeds the active connection limit, it will actually retry multiple times quickly before it starts backing off.