Fix CurlHttpRequest handling unexpectedly large responses

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