Yay for fake timers in tests.

This speeds up the test somewhat, but more importantly, it tests the pipe implementation across a variety of usage patterns.

This actually uncovered a bug in the HTTP implementation: An HttpClient could inadvertently issue overlapping reads in cases where multiple concurrent (pipelined) requests are made.

This lets you construct an AsyncInputStream / AsyncOutputStream pair that operates entirely within userspace, rather than pushing through a kernel-level pipe. This is far more efficient, avoiding system calls and reducing copies.

The pipe does not buffer at all. Instead, it waits for both a read() and a write() call to be active at the same time, and then it fulfills one with the other.

This implementation also optimizes pumps. Imagine the situation: you create a pipe; you call pumpTo() on the write end to pump it to some other; then you write to the write end of the pipe. In this case, the write will *directly* call the target stream to which the pipe is being pumped. Hence, adding daisy-chained pipes on top of a final output stream does not incur additional copies of the data. Similarly, tryPumpFrom() is optimized on the read end.

This is necessary when someone other than the promise owner might need to destroy the state a promise is operating on. It comes up when implementing pumpTo() for userland pipes -- cancelling the pump needs to cancel any writes currently passing through the pipe.

Allow app to send arbitrary Content-Length/Transfer-Encoding in HEAD responses.

Previously, the app could control Content-Length by passing `expectedBodySize`. This is great for enabling code that "just works" by handling GET and HEAD requests identically.

However, in somewhat more-complicated situations -- especilaly in proxies -- you end up having to write special-case hacks for HEAD requests to deal with the fact that the body is actually empty, but has a non-zero "expected" size.

We can make life easier for proxies by allowing the application to directly set the Content-Length and Transfer-Encoding headers in the case of HEAD responses, much like we allow applications to set WebSocket-related headers on non-WebSocket requests/responses.

This change actually fixes a bug in Cloudflare Workers where Content-Length is not passed through correctly for HEAD responses. No changes are needed on the Workers side (except adding a test).

Ensure '%' signs get round-tripped in URL path, fragment, userinfo

Our query string encoding function (encodeWwwForm()) was already doing the right thing.

I changed the comment in encodeUriPath() to clarify that it's intended to implement a URL class which stores its path in percent-decoded form, not either/or. I was wrong before.

Allow underscores in URL hostnames

We'll need more hostname-related code changes in the future, but for now this will solve a Cloudflare customer's existing bug report.

Distinguish between empty- and null-valued query parameters

Implement various WHATWG URL percent encoding functions

This has the effect of making the authority, path, and fragment components each slightly more permissive in what they don't escape.

According to the WHATWG URL spec, each different component of a URL gets its very own percent encode set, which we've been doing wrong this whole time.

In terms of reserved characters, the fragment set is a subset of the path set, which is a subset of the userinfo set, which is a subset of RFC 2396's reserved set.

Make all tests pass on qemu-aarch64

Tested on qemu-aarch64.

It appears that QEMU:
- Does not correctly set the MSG_TRUNC flag on recvmsg().
- Crashes when we try to use the IP_PKTINFO ancillary message.

So let's skip those tests...

When catching an unknown exception type, at least log the type.

Including cxxabi.h caused build failures because our definition of __cxa_get_globals conflicted with the one in the header (despite being in a different namespace -- apparently becaues of `extern "C"` the compiler considers them to be conflicting). Annoyingly, __cxa_get_globals is only defined by GNU's cxxabi.h and not LLVM's. But LLVM has a nicer __cxa_uncaught_exceptions() that we can perhaps use.

Also in C++17 there is a standard function we can call instead.

Support sending GETs with bodies.

Primarily, we want to support proxies passing through such requests blindly. So, I didn't add any new API for this, just added some hacks so that things "just work" when proxying.

Fix bugs in relative URL parser

The relative URL parser allowed certain hosts which the absolute parser correctly weeded out. This change copies two lines from the absolute parser over to the relative parser.

Explicate List element Kinds in generated code

Various versions of MSVC have various troubles deducing the Kind K of a List<T, K>. This change removes any need for the compiler to deduce the Kind, and just hard-codes it into the generated code.

Fixes #642.

Extend HttpServer to inform the caller when a connection ends cleanly on drain().

This allows an application which calls drain() to potentially pass off HTTP connections to a new HttpServer afterwards. Without this, the application has no way to know if the connections are in an indeterminant state.

This change also makes it OK for an application to fail to read the whole request body. Previously, if an app returned a response without reading the whole request, an exception would eventually be thrown, but potentially not until the client had initiated a new request on the same connection. The client would then get a spurious 500 error.

Escape CMake config var in configure.ac

Instantiating kj::downcast<T, T>() causes a compile failure with -Werror=address because the compiler knows the dynamic_cast check in downcast() can never fail.

Redesign server-side WebSocket handling.

Previously HttpService had two virtual methods: request() and openWebSocket(). Since it's legitimate to respond to a WebSocket request with a normal HTTP response, openWebSocket() actually had a default implementation that fell back to request().

In the new design, there is only request(). The HttpService detects a WebSocket request by checking the headers. A convenience method, HttpHeaders::isWebSocket(), is provided for this purpose.

The new approach makes life much easier for services composed of many layers. For example, you might write an HttpService implementation which performs some URL or header rewrite and then calls on to another HttpService. Previously, every such wrapper would have to separately handle regular requests and WebSockets, usually with near-identical code. Of course, you could factor out the common code, but in practice this often turned out pretty clunky. Worse, developers would often just omit the openWebSocket() implementation since implementing only request() seems to work fine -- until you need a WebSocket, and everything is broken. With the new approach, you have to go somewhat out of your way to write a wrapper layer that breaks WebSockets.

I did not apply the same logic to HttpClient because:

1. It's not as easy: HttpClient's methods return results rather than calling a callback on completion, so unifying the methods would have forced request()'s signature to change. Lots of code would need to be updated, and would likely become uglier, as request() would now have to return a `webSocketOrBody` variant type even when the caller isn't asking for a WebSocket.
2. People don't implement custom HttpClients nearly as often as they implement custom HttpServices.