Ensure CONNECTION_CLOSE is sent on each path during closing state

During the closing state an endpoint should send a CONNECTION_CLOSE in response to packets received. In RFC9000 this is on the single path.

In multipath however we may be receiving more packets on several paths. We send only a single CONNECTION_CLOSE over one of the paths however, which might be broken for whatever reason. So we do need to make sure that each path tracks independently on whether packets were received after the CONNECTION_CLOSE was sent and elicit a new CONNECTION_CLOSE each time. This also means that for those later CONNECTION_CLOSE frames the exact path it should be scheduled on is important.

And while doing this do not forget that ideally there is also some kind of backoff for those, so that not too many CONNECTION_CLOSE packets are sent. That again is as specced in RFC9O00, but I'm not sure this is currently implemented. Maybe that'll be better split off in its own issue though, let's see when we implement this.

Start by tracing the closing-state CONNECTION_CLOSE handling and multipath path scheduling, then compare the behavior with RFC9000. Verify how each path records packets received after a CONNECTION_CLOSE and how later frames are scheduled; done means each affected path receives the required response without excessive retransmission.