Flush ACKs on Stream Closure

[CarnaViire]

Describe the feature you'd like supported

Discovered in https://github.com/dotnet/runtime/issues/71927

Fot HTTP/3 in .NET, which uses MsQuic underneath, client connection closure would happen in Dispose of an HttpClient. However, due to various circumstances, either due to an app being a short one-liner (e.g. PowerShell script) or a client being a shared singleton (e.g. a proposal in https://github.com/dotnet/runtime/issues/65380), the app will most possibly not dispose the HttpClient. That might lead to the last ACK, if it was delayed past the stream closure, never being sent to the server.

The problem would manifest on the server side by the server stream trying to resend the last packets in a hope to get the ack, but never getting it will lead to a connection being torn down in a non-graceful way and the request would deem to be unsuccessful (despite it being successful on the client side). This would lead to the server stream living longer and wasting time on resending packets, as well as unnecessary errors in the logs.

For more information, see the initial issue, where it was observed on a gRPC server: https://github.com/dotnet/runtime/issues/71927

Proposed solution

Flush ACKs on Stream Closure, either always or if a feature flag was set

Additional context

A draft was started in https://github.com/microsoft/msquic/pull/2904. End-to-end tests have shown that in order for this to work, the code should be in Close, not Shutdown (see https://github.com/dotnet/runtime/issues/71927#issuecomment-1194522423).