Bundle flow control and ACK frames opportunistically

[Ralith]

MAX_DATA, MAX_STREAM_DATA, MAX_STREAMS, and ACK frames are all sent automatically by endpoints receiving application data, and usually do not need to be sent at the first opportunity. We currently reduce traffic by relying on a significance threshold (e.g. 1/8 of a flow control window, or a certain time or packet count for ACKs) to judge whether they must be sent. This fails to reliably include these automatically generated frames in packets bearing application data, even if such packets are being sent regularly (e.g. responses to requests).

We could capture this opportunity by introducing an additional, separate, lower significance threshold at which flow control and/or ACK frames will be included in an outgoing packet. If packets are being sent regularly, then this threshold will typically be crossed and a frame included before a free-standing packet would become necessary.

We should be careful not to generate too many ACK frames even when bundled in otherwise-scheduled packets, as they are thought to be relatively expensive for the peer to process. Flow control frames have no such constraint and need only consider the cost of the space to encode them.