Allow changing flow-control window

[nitely]

Right now we set the window to max size (2GB), and send a window update every 1GB (1, 2). Which effectively disables flow-control. Prior to this the window was set to default size, and I was sending a window update for every consumed data frame, which caused a 10x slow down on a big file data transfer.

We should provide a way to set the window size, and add some heuristic that will send window updates only when needed (maybe sending an update every half window size is consumed is fine)

[nitely]

There is no way for the client/server to be overwhelmed by a peer sending data faster than it can be processed because of built-in backpressure. However, not calling recv on a stream promptly will cause it to block all other streams for that connection/socket.

So flow-control is important when dealing with streams of data that won't fit in memory. We cannot keep receiving and keeping all data in memory while it's being processed.

A common use case is receiving a stream of data, transforming the data, and sending it either back or to some other endpoint. If we receive faster than we send the data needs to be kept in memory temporarily. There is no way around it, even storing it on disk could have the same issue where it's slower to write to disk than receiving the data for whatever reason (for example network disks), and either way it's a poor solution to the issue. The right solution is setting a sensible flow-control window so no more than "window size" bytes are kept in memory at a time.

Also, we currently offer no way to control the flow-control. Window updates are sent as soon as data is received. This defeats the purpose of flow-control. The window updates need to be send once the data is effectively processed and released from memory.

In short, flow-control is needed, so a stream that receives data faster than it can process it won't block other streams.

[nitely]

Possible solutions:

• asyncCheck data recv internally, put data in an unbounded string (max size this will reach is window size). Calling recv copies/clears the string, Send window update when calling recv.
• add some param to disallow auto sending window updates. User needs to send window update after processing the data.
• make the stream frames queue unbounded. Send window update when taking from it. Take on recv call. This is similar to the unbounded string solution, but keeping frames is way too expensive I think. If we receive 1byte data frames, the potential size of the queue is window size (initial is 65K) multiplied by the data structure size, which is +16bytes, so +10x the window size. Also probably really bad for the GC.