[QUIC] Define suspend and resume behavior for connection protocol

[markafoltz]

Similarly, for maintaining connections between controllers and receivers, devices should be able to suspend and resume the set of QUIC connections. This issue tracks the work to define the behavior of suspend and resume in terms of the underling QUIC and OSP state.

[btolsch]

The following issues are some that come to mind on this topic:

• W.r.t. the QUIC spec, the PING frame in QUIC is specifically for keeping both the QUIC connection (because of idle_timeout) and the intermediate path state (e.g. middle box/NAT state) alive. Suspend/resume would either need to still allow sending PINGs (and therefore buffering receives) or do nothing and just test the connections after resume.
• Similarly, if no received data will be processed during suspend, the other endpoint might think many packets are being dropped or delayed. Even if the connection is still active on resumption, the congestion control algorithm of the other endpoint will have been negatively affected by the sleep period. It might be beneficial/necessary to communicate with a CBOR message that we are suspending/resuming, though incorporating that into the QUIC flow control implementation would probably be very difficult.
• At the OSP implementation level, we would need to decide whether other parts of the implementation (e.g. Presentation API Controller implementation) can still write to QUIC streams and the data is buffered, or whether writes should be rejected during suspension.

[markafoltz]

Filed #324 to follow up on state synchronization.