Implement shut off valve when dropped packets vector grows to fast

[jstnlef]

Task Description

We currently have an issue where, when a user isn't familiar with how our acking model works, the protocol gets further an further behind trying to send packets it's believed have been 'dropped'. It's so good at this job that, when a client isn't sending responses fast enough, the number of packets a server is sending balloons to ridiculous numbers.

Task TODO

Essentially, if we get some number of consecutive sends where the "dropped queue" is increasing, we should send a final error message, consider the client disconnected, and drop it.

• Make something to count 'send' actions when dropped queue increases in size.
• When the above triggers, consider the client to be disconnected, return Disconnect event.

[TimonPost]

@jstnlef, what is to you the maximum number of times we should detect the growth of the queue before to take actions.

[jstnlef]

Unsure about this. Can play around with a couple of settings but likely anywhere from 3 to 5 sends where the dropped packets vector is consistently increasing.

[kstrafe]

To add to this I think this should perhaps be an optional config value. There may be legitimate cases of queueing up many packets before getting acks.

[jstnlef]

The dropped packets vector is only pushed to if we haven't received an ack for it in 33 packets. Therefore, in the places where this vector is continually increasing, it's safe to say we're in a pathologically bad state.