Add a flag to specify streaming requirements on the request body

[guoye-zhang]

A new flag on HTTPClientRequestBody to explicitly allow a fetch client backend to buffer the request body.

I'm still debating whether using a missing feature should throw or just fatalError to be more obvious.

[czechboy0]

I'm not sure I understand what a body "requiring streaming" means? It's the body that decides whether it writes all bytes at once or if it chunks it up, why would it need to communicate it elsewhere?

[guoye-zhang]

The body always writes chunk by chunk. requiresStreaming (or we can flip it into allowsBuffering) means that the client implementation must support request body streaming, not run the closure to save it all into a buffer and send the buffer. A fetch client that runs in browsers which do not support streaming will throw.

[czechboy0]

Why should the body type make requirements on the client implementation? This type is just a wrapper of a closure, it's the producer of the request body data. All it does it writes the bytes on-demand.

If we want to put specific requirements on the behavior of the client, I think it should go on the client instead.

[FranzBusch]

I'm not sure we need this. I think bi-direcitonal streaming is a requirement that every client needs to support. fetch already supports response streaming and request streaming is being added as well. Let's just make this a baseline requirement.

[guoye-zhang]

The reason this is on the request body is that different call sites might have different requirements. Most uploads have small bodies (e.g. JSON POST requests). For large file uploads or advanced streaming use cases, streaming would be required.

If all client backends support streaming, great, no one needs to check this flag at all. This is for browser fetch that must buffer the body before sending. It defaults to true so perform with a streaming request body would fail unless the user confirms that it's safe to buffer. This prevents accidental stalls / memory explosion.