RESUMABLE: Always allow upload creation requests with no content

[GrantGryczan]

Fixes #3399

[guoye-zhang]

min-append-size and max-append-size didn't apply to upload creation prior to a897702. Would it be easier for implementors for min-append-size to stay not applicable or to carve out a 0-length exception? Also @mertalev

[GrantGryczan]

I suspect having the initial request bypass the limit would be unacceptable in nearly every case where a server would want this limit. It would certainly be unacceptable in the use cases I considered for my own implementation. Here are some examples of usage I considered for my implementation:

• The server is directly submitting each chunk to a multipart AWS S3 upload so it doesn't need its own buffer, and S3 has its own minimum part size that doesn't treat the first part of the upload any differently. This would fail, and the server would need a non-standard way to communicate to the client that they should follow this limit for the initial request.
• min-append-size and max-append-size are both set to the same value to improve the storage and seeking efficiency of each chunk before storing each chunk directly. Letting the first chunk be inconsistently small would increase complexity, waste storage, and harm random access performance.
• A compression algorithm is applied to each chunk before storing the compressed chunk directly, and it would increase complexity to support compression and decompression of variably sized chunks (other than the last one), as well as be wasteful for storage and performance.
• Similar to previous but encryption instead of compression.

[mertalev]

Fully agree with @GrantGryczan. Any server that sets such a limit will enforce it for the first request as well and the client should be able to handle this.

[smatsson]

I agree that a 0-byte exception would be better for the same arguments as above.