It turns out I was testing it wrong, and it still doesn't work. :(

Rewrite JSON decoding

Simplifiy implementation and, as a bonus, allow overflowing floating numbers to convert to +/-Infinity like they do in JSON.parse.

Also update outdated comment about NaN and Infinity being encoded as `null`.

 - Add support for decoding with Orphanage.
 - Allow decoding of non-struct root JSON objects.
 - Add support for custom decoding type handlers.
 - Add support for custom decoding field handlers.

Add flag to kj::Url::parse() to prevent automatic decoding of URL components

I haven't looked at it in years, why waste everyone's bandwidth?

Fix problem on android api < 23

Don't log/throw exceptions if the service returned successfully witho…

Theory is that maybe it did this intentionally, e.g. because it really just wanted to disconnect and it already dealt with any errors. The client should notice the stream ending prematurely so it should be possible for the developer to see the problem from the client side.

Don't throw from ~HttpChunkedEntityWriter after write cancellation.

In theory KJ style should allow this to be caught (it doesn't throw if another exception was already thrown), but I've observed this producing an std::terminate() for some reason.

Improve HTTP body cancellation handling.

Implement newHttpClient(HttpService&).

Fix filesystem-disk-test to support platforms with non-4K filesystem block size

Some memory-based filesystems, namely tmpfs, select their underlying block size
equal to the configured page size of the platform/OS.

On systems with page size not equal to 4K (for example, arm64 can be configured
to have 16K or 64K page sizes -
https://www.kernel.org/doc/Documentation/arm64/memory.txt) "DiskFile holes"
test fails, when creating a file on a memory-based filesystem, because it
"punches" a 4096 byte hole in the file (using fallocate) and expects the number
of filesystem blocks used by the file to decrease. When the system page size is
greater than 4K, 4096 byte hole is not enough to make the OS release the
underlying blocks.

Need to punch a whole, which is equal to the underlying filesystem block size at
least.

MinGW 7.2 (x86_64) build failed

It turns out wrapping an HttpService in an HttpClient is considerably more complicated than vice versa, due to the need for pipes. This commit adds a WebSocket pipe implementation very similar to the recent byte-stream pipe (though considerably simpler since there's no need to deal with mismatched buffer sizes).

 Implement in-process byte stream pipes.

MinGW 7.2 (x86_64) build failed

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.