Guarantee reception report when full red part data is received

[BrianSipos]

In the case where data segments arrive out-of-order and with enough delay that even a deferred reception report (#22) has some gap in it, there may be a point where the full set of data is received (with no retransmission, only out-of-order in the first flight). When this happens the receiving engine must guarantee that an "asynchronous reception report" (one not in response to a checkpoint) is sent so that the sender knows to stop any data retransmission that hasn't yet gone out.

I don't know if this is currently implemented, but I can prepare a small test fixture to exercise this situation.

[BrianSipos]

This is a report guarantee in the sense that if the last received red segment that completed the red part data was a checkpoint there's no need for an async. reception report. Only when the red part data was completed by a non-checkpoint segment is the async. reception report needed.

[briantomko]

I am adding additional details to Github issue 23:
Do not send the async reception report if this non-checkpoint segment filled all the gaps of a pending/delayed reception report (thus immediately sending it out) AND that reception report had lowerBound == 0 and upperBound == lengthOfRedPart

If the sender detects that all Red data has been acknowledged by the remote, the sender shall remove all Red data segments (checkpoint or non-checkpoint) from the outgoing transmission queue.

[briantomko]

This issue has been resolved by commit 85316fe. I added this to side branch 111-defer-reception-reports and will close the issue when it's merged into master.