Allow application event to influence batch sending

[tfpauly]

Allow the application to send events to start and end output batching. This causes a protocol (like QUIC) to not process outbound application data until the batch is complete. This helps improve efficiency when sending.

[agnosticdev]

A few questions here; it looks like you are pending all stream writes by default here and I don't see anything in the QUICTestHarness setup that unblocks the standard path. So I am guessing what is happening is that when inboundStopping is called this path actually sends the stream frames even if you have pendOutboundData set to false and that is how all of the unit tests are passing. Is that what was intended to happen here?

Next question, based on the answer I guess of the first question, do we want to gate the inboundStopping path too on the receive side with these events? For example inboundStopping -> sendFrames.

[tfpauly]

@agnosticdev not quite — this is not pending anything by default, and not changing any of the default behavior. The pending/batch behavior specifically requires the application above to send the notification to start and stop pending sends. At the time of un-pending sends, the deferred sendFrames call is invoked.

You're correct that inboundStopping (and other functions) are still allowed to trigger sendFrames. This is important to ensure that inbound packets can still be acked, etc. This batching is really a hint to improve coalescing of application data. In normal use, all of the send operations would be occurring from the application side before feeding data in from below anyhow, so it will work exactly as intended.

[agnosticdev]

@agnosticdev not quite — this is not pending anything by default, and not changing any of the default behavior.

Right, I missed that the guard was actually checking the inversion of pendOutboundData.