Fix CurlHttpRequest handling unexpectedly large responses
This fixes a few issues with CurlHttpRequest (and correspondingly GcsFileSystem):
- Return status FAILED_PRECONDITION (i.e. "your buffer was too small") when CurlHttpRequest has a direct response buffer and the response is too large for the buffer, instead of UNAVAILABLE, since if the server resource is actually a fixed size, retrying automatically won't help at all. Also, include the message about the too-small buffer size in the returned Status as opposed to logging it, making it more obvious that it's treated as a message about a hard failure versus just a warning.
- If the response was actually a 416 Range Not Satisfied response, fully pretend that the response had no body even if we got one (I'm looking at you GCS... it returns a 177-byte error message). This means:
- Ignore a "buffer too small" error produced by the logic described above
- Don't report the length of that body in GetResultBufferDirectBytesTransferred(), which looks to the client like data corruption, just report 0 (this fix makes it match the behavior of the non-direct-buffer response handling)
I also tweaked the error messages, e.g. the message that includes an HTTP response code shouldn't report the CURLcode since it will always be CURLE_OK at that point.
PiperOrigin-RevId:
197805003