3x amplification limit for CONNECTION_CLOSE

We weren't very concrete in saying how endpoints generate packets with
CONNECTION_CLOSE, particularly those that throw away keys.  We have
a rather vague requirement.

In short, follow the same rules we established for the handshake.
Wording this as an aggregate number allows for stochastic reactions and
larger CONNECTION_CLOSE frames.  This way, if you get a 25-byte packet
and respond with a 200-byte packet, you can do that, but you have to
respond to 3 in 8 or fewer in that way.

Note that this limit only applies if the endpoint throws away decryption
keys.  Endpoints with keys aren't blind amplifiers.

Closes #3845.

draft-ietf-quic-transport.md

@@ -2743,10 +2743,11 @@ An endpoint is allowed to drop the packet protection keys when entering the
 closing period ({{draining}}) and send a packet containing a CONNECTION_CLOSE in
 response to any UDP datagram that is received.  However, an endpoint without the
 packet protection keys cannot identify and discard invalid packets.  To avoid
-creating an unwitting amplification attack, such endpoints MUST reduce the
-frequency with which it sends packets containing a CONNECTION_CLOSE frame.  To
-minimize the state that an endpoint maintains for a closing connection,
-endpoints MAY send the exact same packet.
+creating an unwitting amplification attack, such endpoints MUST limit the
+cumulative size of packets containing a CONNECTION_CLOSE frame to 3 times the
+cumulative size of the packets that cause those packets to be sent.  To minimize
+the state that an endpoint maintains for a closing connection, endpoints MAY
+send the exact same packet.
 
 Note: