Add new large body conformance tests

[xbhatnag]

Motivation

For our definition of a large body (1Mb), ensure that clients can:

• make requests to a server with large body
• receive responses from a server with large body
• under-read a response from a server with large body

Modifications

Wrote 2 conformance tests:

• test1MbBody writes a 1Mb body in a request to the /echo endpoint. The server echos the response back and the client verifies that it got back the exact same data.
• testUnderRead makes a request to the new /1mb_body endpoint and only reads 1 byte in the response handler.

Unfortunately, testUnderRead did not pass on URLSession or AHC.

On AHC, attempting to under-read causes a precondition assertion failure here which needs more investigation.

For URLSession, the bug is that an under-read puts the state machine into a situation where:

• the URLSession data task has been suspended
• the post response callback handler hangs on the callback stream because the URLSession data task has been suspended.

A fix for this bug in URLSession is also included in this PR. The solution is to cancel the URLSessionTask once the response handler has executed. If the request is not already complete, this will cause the completeWithError handler to be triggered which will unblock the callback stream.

Result

These tests both pass with the URLSession client. test1MbBody passes with AHC and we will investigate why under-read is failing on AHC.

Test Plan

The raw requests and responses were verified manually with Wireshark.

[guoye-zhang]

Does this throw? I'm wondering if we should always throw if the entire response body wasn't read

[xbhatnag]

No, it doesn't throw for reading less. I don't think it should? It's valid for a client to just want to read an initial portion of the response before moving on. Real-world examples would be things like:

• Content probing (media players reading only the initial bit of the file to get metadata)
• Search/grep in large remote files

[guoye-zhang]

I'm worried about truncation issues where people only call read once, and usually get the entire body when it's small, but the code fails randomly when the body is bigger. Cancellation throws an error and this is a cancellation.

[xbhatnag]

I see how that can happen.

Here are my concerns:

1. If we're talking about CancellationError specifically, that is strictly about a task being cancelled. There was no task that was cancelled here explicitly by the user.
2. Throwing an error in this case can encourage a pattern where the user wraps their call in a do-catch that does nothing in the catch, because they intended to stop halfway. That is awkward IMO.
3. From the "socket-is-a-file" philosophy, there isn't a file API I know of that throws an error because we closed the file halfway through and didn't read it entirely, even if the close is implicit like in Python:

with open("myfile.txt") as f:
    f.read(1024)

That being said, python also makes it convenient to read "everything" by just omitting the size parameter. Maybe what we want here is some convenience functions to read until EOF, so users don't accidentally reach for the POSIX-y socket best-effort read?

[guoye-zhang]

collect is supposed to be that. Honestly I think this is somewhat a bug in collect because it's returning nil as trailer which might be incorrect since we wouldn't have read the trailers before the end of the body. This is somewhat related to #52

[guoye-zhang]

In URLSession at least, you have to cancel the task and receive a -999 error, otherwise we would keep delivering the body.