While swapcontext() exists on Cygwin, it seems that throwing an exception in a stack other than the main stack leads to a hang. But the Win32 fiber API seems to work fine.

It was so easy that it compiled on the first try and almost totally worked... only thing I missed was calling switchToMain() explicitly at the end of the fiber main func.

Fibers allow code to be written in a synchronous / blocking style while running inside the KJ event loop, by executing the code on an alternate call stack and switching back to the main stack whenever it waits.

We introduce a new function, `kj::startFiber(stackSize, func)`. `func` is executed on the fiber stack. It is passed as its parameter a `WaitScope&`, which can then be passed into the `.wait()` method of any promise in order to wait on the promise in a blocking style. `startFiber()` returns a promise for the eventual value returned by `func()` (much as `evalLater()` and friends do).

This commit implements fibers on Unix via ucontext_t. Windows will come next (and will probably be easier...).

Instead of making `Promise` friend everything that needs to construct a `Promise<T>` from an `Own<PromiseNode>` or vice versa, let's just friend `PromiseNode` itself -- which is already a "private" class by virtue of being in the `_` namespace -- and let it provide some static methods to do the conversions.

Override Content-Length and Transfer-Encoding in http-over-capnp.

Some applications expect to be able to inspect these headers in order to learn about the properties of the entity-body. Currently, over RPC, the sender could send arbitrary header values that have nothing to do with the actual body. Instead, let's just overwrite them to match.

Fix RPC loopback bootstrap().

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.