ASGI resp.stream is iterated until completion despite client disconnect

At the time of writing, setting resp.stream to an async generator results in it being iterated by the framework until completion (or, obviously, until an exception is raised) regardless whether the client has already disconnected. The SSE code path already has a mechanism to poll and detect the http.disconnect ASGI message.

This issue intersects with #1808, however this one proposes that the framework should detect the disconnect event and stop iteration itself, as it is done for the SSE case. Maybe both cases could be generalized that setting resp.sse would simply set the Content-Type and resp.stream, and further streaming would use the same logic?

If implemented, this behaviour would probably interfere with "true" full-duplex HTTP streaming, i.e., where the request's body is being streamed to the server, while the server is streaming response simultaneously. I've tried skimming through RFC 2616, however it is not crystal clear whether this is allowed or not. The RFC just states it's forbidden for the client to continue streaming if it has received an error response. Some people claim it is possible, see, e.g., Does HTTP 1.1 Support Full Duplex Communication? Obviously, not all clients and servers supports this. For instance, the popular Uvicorn states that:

Once a response has been sent, Uvicorn will no longer buffer any remaining request body. Any later calls to receive will return an http.disconnect message.

However, theoretically other ASGI servers might still choose to support this scenario... Is it maybe possible to detect this somehow (that receive() is still returning data after send() and buffer a couple of messages :thinking:)?

https://github.com/falconry/falcon/issues/1956 might also be loosely related.