When VatNetwork::connect() returns nullptr, it means that the caller is trying to connect to itself.

rpc-test.c++ failed to test this in two ways:
- The test VatNetwork's connect() never returned null.
- There was no test case for loopback connect.

As a result, the code to handle loopback in rpc.c++ had bitrotted. It failed to handle the new bootstrap mechanism introduced in v0.5, and instead only implemented the restorer mechanism from 0.4.

Update tls-test for BoringSSL changes.

tls-test: Update error message to match new boringssl behavior

Note that I only care about supporting BoringSSL at master since BoringSSL does not do versioned releases.

Introduced in 58d56f4c5 ("Enable TLS 1.3 by default").

Add getsockname() to ConnectionReceiver.

This is a no-brainer given AsyncIoStream has getsockopt() and getsockname(), whereas ConnectionReceiver has only getsockopt().

Make HttpClient adapter preserve exception behavior

Ideally, the HttpClient/HttpServer adapters should maintain the invariant that
the behavior of a given client is the same as the behavior of
newHttpClient(newHttpService(client)).  Prior to this change, the HttpClient
wrapper lazily called request(), so a client whose request() eagerly threw an
exception could produce a different exception when called directly versus when
wrapped -- the laziness allowed additional code to run.  This was particularly
evident when making a request with a body, since code using a wrapped client
would be able to set up a subsequent BlockedWrite, eventually resulting in a
"read end of pipe was aborted" exception instead of the actual exception.

This change makes HttpClientAdapter::request() execute the wrapped request()
eagerly.

(Note that it partially undoes 90d48343... Hopefully, it preserves the desired
behavior added there.)

Detect and report when a HashMap suffers from excessive collisions.

Fix failures in http-over-capnp-test.

`task` needs to be the last member of ServerRequestContextImpl, because when we construct it, we call `service.request()`, which may call back to send() or acceptWebSocket(), which require `replyTask` to be initialized.

And fix a bug detected by this.

Various bug fixes

The RPC system itself can sometimes call `releaseParams()` redundantly after the application has already called it. So, it's important that it be idempotent.

Add std-iterator.h to build files

Suppress MSVC warnings in headers files

Add compat/std-iterator.h

Allow including a header to obtain the iterator traits instead of
needing to carefully define a slightly more obscure macro that someone
might be tempted to define globally.

For Visual Studio we have to wrap the headers with push/pop pragmas
at the top and bottom of the file.

Define common macros for suppress/unsuppress KJ & the appropriate macros
for CAPNP begin/end header wrappers. Because there's a chicken egg
problem the KJ_BEGIN_HEADER/CAPNP_BEGIN_HEADER macros are placed below
all includes to ensure that the appropriate common.h file has been
sourced.

Fixes #889.

Fix handling of queued RT signals, plus some other crap

For regular (non-RT) POSIX signals, the process can only have at most one instance of each signal queued for delivery at a time. If another copy of the signal arrives before the first is delivered, the new signal is ignored. The idea was that signals are only meant to wake the process up to check some input; the signal itself is not the input.

POSIX RT signals are different. Multiple copies of the same signal can be queued, and each is delivered separately. Each signal may contain some additional information that needs to be processed. The signals themselves are input.

UnixEventPort's `onSignal()` method returns a Promise that resolves the next time the signal is delivered. When the Promise is resolved, the signal is also supposed to be blocked until `onSignal()` can be called again, so that the app cannot miss signals delivered in between.

However, the epoll/signalfd implementation had a bug where it would pull _all_ queued signals off the `signalfd` at once, only delivering the first instance of each signal number and dropping subsequent instances on the floor. That's fine for regular signals, but not RT signals.

This change fixes the bug and adds a test. Incidentally, the poll()-based implementation has been correct all along.

I don't really know how to test this since the other cmsg types are bizarre and non-portable, but they do exist.

This and many other characters are surprisingly allowed by the relevant RFCs. But it turns out we implemented the RFCs correctly, so yay.

I initially didn't read the docs carefully enough and returned a StringPtr to a locally allocated string. Whoops. Make the doc a little clearer about this.

Increase arenaSpace for emscripten builds

kj::atomicAddRef(): Fix assertion error message

 Define and implement HTTP-over-Cap'n-Proto

It seems like MSVC is generating this function in translation units where it isn't acutally called, which inadvertently causes non-RPC Cap'n Proto code to depend on kj-async.