support streaming responses in request-response protocol

[dvc94ch]

currently if a request results in multiple responses you can't use the request-response protocol. I wonder how hard it would be to add a final_response method to the request response behaviour and keeping the channel open until the final response.

[romanb]

My first impulse would be to have a dedicated crate for generic streaming-oriented protocols, where any number of "chunks" can be sent in either direction on a single substream. libp2p-request-response is really designed for RPC-like "1-request, 1-response" protocols and bending it to serve different needs may be too cumbersome and restrictive on what you can do. But this is just my "gut feeling" without having made a proper analysis or experiment with the necessary changes. This may be a duplicate of #1727.

[dvc94ch]

Closing as a duplicate for now, but many rpc api's support some kind of pubsub and it would be nice to reuse the underlying stream instead of opening a new one for each notification.