This leaks due to the old compiler bug:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799
http://llvm.org/bugs/show_bug.cgi?id=12286

Previously we only closed immediately after a response finished.

If recvData is empty, recvData.begin() is a null pointer and binding a Header reference to it is invalid.

Detected by -fsanitize=null.

(Or if it didn't send the entire request body.)

There are actually two new client types:
- One which always connects to a given NetworkAddress, but will automatically manage a pool of reusable connections.
- One which looks up the remote address based on the URL it is given, and manages a pool of connections for each host.

The latter of these two is a "true HTTP client library".

This really is more of a data structure than a resource type, and it's useful to be able to share it between threads and whatnot.

The proxying code was responding to a `Close` message by ending the pump loop, which had the effect of immediately dropping the connection after a `Close` had been seen in each direction. This is arguably incorrect behavior: for proxying purposes, `Close` messages and underlying TCP disconnects should be treated as independent events, forwarded separately.

In practice this "bug" probably would never cause a problem and perhaps doesn't even violate spec (since `Close` was seen in both directions). But, OSX's implementation of shutdown() returns ENOTCONN if the connection has already been disconnected from the remote end. This is the case here, as the proxy dropped all connections immediately after sending the final `Close`.

This in turn led to a unit test failure.

The intended behavior was that the proxy would forward exactly what it saw: If a `Close` was sent, it would be forwarded, without changing the underlying connection state. If a TCP disconnect was detected, it would be "forwarded" by disconnecting the next leg. This change implements that behavior.

Due to differences in the way I/O events are queued on Windows, the timing of this test end up different, such that the two incoming pings are not both received before the large outgoing message is sent.

To fix this, I removed the dependency on native I/O altogether by implementing an in-memory pipe that does no buffering (it requires a read() and write() to rendezvous, then copies between their buffers).

Still need to add handshake separately.

It turns out that, quite often, the write() will have already completed before the method returns, hence dropping the returned promise won't cause any apparent problem -- until you try to write() a sufficiently large value that it doesn't complete on the first call. Then, you get mysterious bugs.

Indeed, it turns out the HTTP library has such bugs, which are fixed in this change.

This uncovered some bugs and revealed that there was no way to read the Content-Length of a HEAD response. Fixed.

It looks like it's pretty normal for browsers to do this.

The entity-body would never be marked "done", breaking the pipeline for subsequent requests/responses.

(In practice `Content-Length: 0` is rare since normally only GET requests don't have content and they don't pass `Content-Length` at all.)

This reverts commit f836a5fc.