ACK-only feedback loop in recovery instead of transport

[rmarx]

Currently, it's the transport draft that mentions ACK-sending behaviour for ACK-only packets:

Implementations MUST NOT generate packets that only contain ACK
frames in response to packets which only contain ACK and PADDING
frames.

and

To avoid creating an indefinite
feedback loop, an endpoint MUST NOT send an ACK frame in response to
a packet containing only ACK or PADDING frames, even if there are
packet gaps which precede the received packet.

and

Because ACK frames are not sent in response to ACK-only packets, a
receiver that is only sending ACK frames will only receive
acknowledgements for its packets if the sender includes them in
packets with non-ACK frames. A sender SHOULD bundle ACK frames with
other frames when possible.

This feels like it should be moved or at least mentioned again in the recovery document (e.g., in the current 4.4 Generating Acknowledgements).

[ianswett]

Agreed. We have a few things which are mostly duplicates between recovery and transport, which is unfortunate, but I think ends up being helpful in cases like this?

[ianswett]

I'm not sure what the right answer is here, but I'm assigning this to Jana, since he's an editor on both docs.

[ianswett]

Agreement from London was to move as much as possible to transport, and cite transport when possible.

Martin suggested almost all of section 4 can be moved: https://tools.ietf.org/html/draft-ietf-quic-recovery-20#section-4

[ianswett]

I created a PR that moves the text and removes text that is incorrect or misleading. It still needs some editorial work, but I believe @martinthomson prefers a simple move first and then we can polish it up in a different PR?

Most importantly, is there anything that I removed that should stay in Recovery? Nothing stuck out to me.