Resend CLOSE Frame in Closing State

[nibanks]

Describe the bug

Per spec (link):

An endpoint in the closing state sends a packet containing a CONNECTION_CLOSE frame in response to any incoming packet that it attributes to the connection.

An endpoint SHOULD limit the rate at which it generates packets in the closing state. For instance, an endpoint could wait for a progressively increasing number of received packets or amount of time before responding to received packets.

We don't seem to ever be sending a CLOSE frame beyond the first time we send it. So, in the case of packet loss the peer doesn't ever get the indication of connection closure. We should fix this.

Affected OS

• Windows
• Linux
• macOS
• Other (specify below)

Additional OS information

No response

MsQuic version

main

Steps taken to reproduce bug

Close a connection and then lose that first packet.

Expected behavior

The peer should usually get the close on a restrasmit.

Actual outcome

It never does

Additional details

No response