receive buffer cleanups

[bagder]

Here's a series of 18 smallish commits that cleans up buffer use all over libcurl. I want to make sure the receive buffer is only used for actually receiving data, and ultimately make sure our different buffers don't all reuse BUFSIZE so that we can have the buffers shrink/grow more independently and controlled.

Changes include:

1. Stop clobbering the receive buffer for small private sprintfs()s and move those to private stack arrays instead
2. Make sure buffer_size is always set and represents the current buffer size length
3. Use the buffer_size variable everywhere instead of BUFSIZE for receive buffer length since we've asked for a buffer of that size. Accessing the receive buffer beyond buffer_size should be a mistake/error.

And since the buffer is actually used to receive data and some of our code cannot handle streaming data completely, the receive buffer must have a certain size to still let libcurl function properly. One patch in this set thus sets the minimum buffer_size to be 1024.

[mention-bot]

@bagder, thanks for your PR! By analyzing the history of the files in this pull request, we identified @jrn, @dfandrich and @captain-caveman2k to be potential reviewers.

[bagder]

Test 1060 fails miserably if we allow the receive buffer to be smaller than about 16K, so I'm now considering either

1. Use 16K as the minimum buffer size to set or
2. Allocate and use a separate and dedicated buffer for the proxy CONNECT logic and then ditch that once the connection is made

[bagder]

It feels lame to limit the ability to set the receive buffer size because we need a buffer for CONNECT, so I'm going for alternative (2): a separately allocated and short-lived buffer for that.

[jay]

Do you think there might be some logic issue in CONNECT that contributes to this, in other words a bug that is just separate from this issue? Say you make a separate buffer, and host foo sends an even larger amount than 1060, then maybe CONNECT would still fail?

[bagder]

Say you make a separate buffer, and host foo sends an even larger amount than 1060, then maybe CONNECT would still fail?

Yes, that's for sure. The CONNECT code is written to work with a fixed-size buffer and if the response is larger than so, it will break. So yes, that's a separate issue that should be worked on separately. But I would also expect that it is a very rare happening to see such big response to a CONNECT.