Fix bug where calling a list setter using a list obtained from a similarly-typed getter, but where the underlying pointer was null, would write an incorrectly-typed pointer in the destination (specifically, an empty List(Void)). Now it sets an empty list of the correct type.

Unfortunately, the layout algorithm had a bug which caused incorrect layout when declaring a union whose lowest-ordinal field was of type Void and nested in an inner union. That is:

    union {
      a :union {
        b @0 :Void
        ...
      }
      ...
    }

In this case, all the fields in the struct after the Void field -- including both unions' discriminants -- would end up misplaced. Although they did not end up overlapping (and therefore the incorrect layout "worked"), the result broke schema evolution rules around "retroactive unionization".

Unfortunately, we must break compatibility with any protocol that happened to contain the above pattern. Luckily, it's a fairly obscure case. Unluckily, Cap'n Proto's own schema format contains such a pattern. Luckily, the use of this pattern was introduced in v0.6.x and therefore has not been in any release build so far.

It turns out that somehow these templates were missing InternalOwner and
ExternalOwner definitions, which was causing problems if a RealmGateway
was defined with them.

Don't kill the connection just because someone pipelined on a capability pointer that turned out to be null.

Maybe::emplace() should return the newly-constructed value so that you don't have to immediately KJ_ASSERT_NONNULL it.

This avoids an unused function warning for crashHandler.

Fixes a build error on GNU/Hurd.

Fix bug where capability pointers were corrupted when 'transferred', e.g. using adoptWithCaveats() or truncate().

Add ability to construct a new bootstrap capability for each connecting client based on their authenticated VatId.

- Reduce noise.
- Trace through async callbacks.

https://llvm.org/bugs/show_bug.cgi?id=22354

At the time DisallowConstCopy was introduced, GCC 4.7 and Clang 3.2 refused to allow the non-const copy constructors to be defaulted inline. This must have been concluded to be a compiler bug, as GCC 4.8 and Clang 3.4 seem fine with it. So, we can clean this up.

Meanwhile, the above-linked Clang bug triggered when a DisallowConstCopy derivative is captured by value in a C++14 generic lambda. capnp::CallContext in particular tended to be hit by this a lot. The bug only affects non-default (or out-of-line default) copy constructors, and thus is conveniently sidestepped by this change.

Add simple convenience classes for using TwoPartyVatNetwork as client or server, since I find myself rewriting this code over and over.

AnyList::operator== is not inline but was declared as such. Also made formatting of operator declarations consistent.