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.

Although contrary to conventions, it's surprisingly easy to write code that calls connect() and then drops the address before the connection completes, and such code works with the default network implementation, so let's accept it.

We'll need to update the configure script to check for OpenSSL and conditionally build this. Ekam users will need to add -DKJ_HAS_OPENSSL to their CXXFLAGS if they've arranged to link against the correct libs.

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.)

or, the world's least significant pull request.

This reverts commit f836a5fc.

Otherwise, the HTTP client might be destroyed before it has written all data, since the responses have already been received.

In particular this fixes http-test on Win32.