🌊 Enable restricting max bandwidth of incoming streams

[haydenmc]

Fixes #42

This change introduces the FTL_MAX_ALLOWED_BITS_PER_SECOND configuration, providing a means of restricting the maximum bandwidth any given stream is allowed to consume before it is kicked off the server.

There are a few other changes in this payload as well:

• FtlControlConnection::FtlResponseCode enum is introduced (from ftl-sdk), and is now referenced instead of hard-coded string values throughout FtlControlConnection.
• Better locking mechanisms around NetworkSocketConnectionTransport's stopping procedure to prevent getting into a deadlocked state if the server is trying to stop a stream around the same time a client is.

An issue #79 was also discovered where pending writes to a NetworkSocketConnectionTransport aren't flushed when the connection is stopped, preventing us from communicating the response code to the client before closing the connection.

Worth noting as well is that OBS behavior when a stream connection is terminated (even with a valid error response) is to reconnect every ten seconds, regardless of the error received. The net user result is OBS transparently trying to reconnect in a loop despite the server kicking them off for excessive bandwidth use.

[Cykotiq]

sounds like an OBS bugfix is needed

[clone1018]

I pulled some data based on the previous week (Tuesday Feb 8th to now) for Glimovies.

(I think it's safe to ignore the initial peak)

Avg: 4011980 bits/s

Glimovies's uses:
Encoder: x264
Rate Control: CBR
Bitrate: 4000Kbps

Of course the video files themselves greatly vary in bitrate scene to scene.