Streaming of requests and responses

[martinthomson]

This is my first rough at streaming. For simple uses, the imposition is
minimal: a single zero byte at the start, with no change to the way
that the content of that chunk is protected. If there are multiple
chunks, then the preceding chunks are each length-prefixed.

Working on an implementation for this.

Closes #75.

[tfpauly]

Thanks for writing this up. It certainly helps clarify things.

I can see that this would be useful for some use cases that relied on very large messages (I'm not aware of these use cases at the moment, but I could imagine they exist). However, fully supporting this does add complexity to the processing and state machine.

I don't fully accept that the impact of this on a client or server that doesn't want to stream messages is just to add the 0 byte and reject things that don't have a 0 there. If I'm only ever talking to rev-locked servers that are entirely coordinating with me, then that could work. But that isn't really sufficient, and I think any client would need to handle parsing of streamed messages, or accept that they will receive unparseable messages.

The fundamental issue is that there's no way for the client to tell the server it doesn't support streaming. So a future version of the server (assuming I'm running an old client that doesn't upgrade often) may start one day getting streamed messages that it doesn't support, and will drop the messages. The server will think everything's OK.

I'd much prefer to see this support gated by a separate content type that can be negotiated with Accept, etc. It'd be fine to still include that in this document as "streaming mode" which can be supported if needed.

It also allows applications that use OHTTP to more clearly have something to point to and define that they MUST support the non-streamed message type if they always expect to have atomic and relatively small messages.

[martinthomson]

On consideration, I think that we should do as @tfpauly suggests and look at providing a different media type. That might provide a control surface we can use to incrementally deploy new formats. I will start a discussion about what we might need to do to enable changing formats. It's not that simple, but the shape of the problem is very much like the one we have with key configuration (and consistency).