Support for stream-oriented protocols

[mzabaluev]

The trait infrastructure of NetworkBehaviour, ProtocolsHandler etc. is very generic, so stream-oriented protocols should be possible to implement. Streamed processing is useful for efficiently implementing transfers of bulky sequences of messages, where the receiving party can cancel the transfer early or apply back pressure to avoid buffering large amounts of data.
However, the utilities available in the library are geared towards unary request-response exchanges:

• The protocol handler in the request_response module encodes and decodes one message per substream. The substream I/O object is passed to the codec by reference, so it's not possible to take ownership of it to return a stream object as a decoded message.
• OneShotHandler could be a better fit, but its connection_keep_alive implementation only regards outbound substreams under negotiation when deciding whether to keep the connection alive. When stream or sink objects corresponding to protocol requests or responses are given to the NetworkBehaviour impl or to the application to use, the keep-alive logic should keep track of the substream handles that are in use.

It would be nice to have a stream-oriented equivalent, or possibly a generalization of, RequestResponse, so that the library users would not need to implement substream management on their own.

[wngr]

Wouldn't it be possible to refactor the request_response behaviour in such a way, that a codec can read (respectively write) >= 1 message from the I/O object? This probably would mean though, that the current design using the upgrade mechanism to exchange messages won't work anymore, and some book-keeping would need to be done inside the ProtocolsHandler.

Anway, I very much agree with the need for a stream-oriented RequestResponse protocol, basically comparable to channels.

[thomaseizinger]

Closing in favor of #2657.