Issue

When using app-provided receive buffers, the current behavior of MsQuic is to set the receive window size to the amount of provided buffer space.
This means that if the app doesn't provide enough buffer space, the stream will be soft-locked: the sender will be waiting until the receiver increase its receive window, which will happen only if the application provides more buffer space.

The application can track the amount of buffer provided and consumed to know when it reaches this situation and could theoretically terminate the stream.
This request is assuming an application side issue and ask for a clear signal that the stream ran out of buffer space.

Proposed solution

• Remove the receive window restrictions
• When the receive buffer does not have buffer space for the received data, a notification should be sent to the app, giving it a chance to provide more buffer space. If the application doesn't, the stream (connection?) is terminated. The app could also return a value meaning "abort this stream" from the notification handler.