In setPromise() we chain `task` with an error handler that accesses ResponseImpl, so that means `task` needs to attach a reference to RespnoseImpl... ugh.

Typos in comments

Make HttpServer detect client disconnect and cancel request processing

Skip whenWriteDisconnected() tests on Cygwin, where they don't seem to work -- the promise never resolves.

Fix HttpClient-from-HttpService wrapper prematurely cancelling service promise.

The test "WebSocket pump disconnect on send" tests what happens if a send() throws DISCONNECTED while pumping. The test hung forever with socketpairs because the message fits entirely in the socket's send buffer, and thus send() actually completes before the disconnect occurs. This differs from userspace pipes, where there is no buffering, and so the send() doesn't complete until all data is received.

This could be fixed by sending a very large message, so that the send() actually blocks on the receiver. But, the problem reveals that WebSocket pumps won't notice when the destination disconnects unless the source sends some message through. Now that we have whenWriteDisconnected(), we can fix this and proactively end the pump, which also fixes the test.

In fact, we can and should propagate such disconnects backwards: if the destination disconnects, we should close the source. We can do this by adding an abort() method to WebSocket, which incidentally allows us to remove the internal AbortableWebSocket interface which was used specifically by WebSocketPipeImpl.

This prevents a hanging service from being a permanent memory leak -- as long as the client is still there waiting.

(TCP servers will need additionally to apply connection-level timeouts/keepalives to detect disappearing clients.)

I decided to make the new method pure-virtual as I wanted to make sure that all wrapper streams properly delegate to the inner stream. We wouldn't want e.g. proactive HTTP cancellation to unexpectedly not work when running over TLS.

This will allow the HTTP server to detect when a client has disconnected and cancel processing the response.

This reverts the core change from: https://github.com/capnproto/capnproto/commit/6e4c5ce3c9f31a5e79b50cd9eaae6d03106edf98

There are a few reasons to believe that change was wrong:
- It meant that a pump would always throw and catch a DISCONNECTED exception, which violates the rule that we don't throw exceptions in "normal" operation.
- It could lead to trouble when combined with the previous commit, which could delay WebSocket disconnect until the service "completes" -- which would lead to a hang.

The commit message where I introduced this said something about bad behavior on OSX. We should address that directly, if it is still a problem.

The client app will typically discard the returned response body upon reading EOF. However, the server app may not actually be "done" with the service callback yet at this point. Usually it completes very soon after, but it may need another turn or two of the event loop. If the client discards the response body stream, the server-side promise is discarded, cancelling whatever was left. This is awkward, so we should instead delay the client from seeing EOF until the server has actually finished up.

Log more info in VectorOutputStream::write() KJ_REQUIRE

This seems to be the case, for example, on WSL.

Detect EOF in copyChunk

This is to help debug an issue in Cloudflare Workers. I also added the same debug info to the ArrayOutputStream case, mostly for pleasing symmetry.

If holes are not supported on the target system and size to `copy` was passed as `kj::maxValue()`, this could lead to near-infinite loops.

Fix cancellation in AsyncTee::PumpSink.

Typo in c++/src/kj/array.h

Fix overflow in PackedInputStream.

Multi-host HttpClient shouldn't rewrite URL.

Fix typo

Extend kj::Url with option to not collapse empty path/query components.

Add `group` to the list of possible annotations targets.

initialize anonymous enums in isPlausiblyText() and isPlausiblyJson()

This is to fix a complaint about Cloudflare Workers removing these components as requests pass through, which apparently breaks someone's funky URLs.

Arguably "." and ".." processing presents a similar problems. But, allowing ".." to pass through is much more likely to lead to security problems. Browsers will generally process "." and ".." before sending a request (whereas they won't collapse double-slashes), so we're following their lead here.