Space for PATH_ACKs and CONNECTION_CLOSE in close packets

Whenever we send a CONNECTION_CLOSE frame we also include ACK frames, to give the peer a chance to get the best picture of which packets were received and which were not. The (PATH_)ACK frames are sent before the CONNECTION_CLOSE frame itself to maximise the chance that they are processed by the peer.

However to correctly follow the close procedure we MUST ensure that each packet has sufficient space for the CONNECTION_CLOSE frame, which can include some variable-length data due to the reason. This used to be essentially statically ensured when there was only a single path. However with multipath there is no real static limit on the space that PATH_ACK frames would occupy.

We should improve the building of the packets with CONNECTION_CLOSE so that we only put in enough (PATH_)ACK frames that we can still write a usable CONNECTION_CLOSE frame into the packet.

Locate the packet-building path that emits CONNECTION_CLOSE together with ACK and PATH_ACK frames. Trace how available packet space and variable-length close reasons are handled, then verify that every close packet retains enough room for a usable CONNECTION_CLOSE frame, including with multipath.