According to David Klempner, this turns out not to be a safe assumption:

https://twitter.com/CaptainSegfault/status/1112622245531144194

Interestingly, it turns out this optimization was also blocking the delivery of certain errors, because we would skip the read() where that error would otherwise be delivered. (Hence the unit test update.)

An endpoint (subclass of `Capability::Server`) may override `kj::Maybe<int> getFd()` to expose an underlying file descriptor.

A remote client may use `Capability::Client::getFd()` on the endpoint's capability to get that FD.

The client and server must explicitly opt into FD passing by passing a max-FDs-per-message limit to TwoPartyVatNetwork and using Unix sockets as the transport. Nothing other than that is needed.

This is just the protocol change, not implementation.

Previously, FDs could only be sent separately from data, with the underlying implementation actually sending a dummy one-byte message.

For Cap'n Proto FD passing, it's better if we can attach the FDs to the RPC message they arrived with, because it avoids the need to pre-negotiate where FD passing is supported: if the sender sends FDs but the recipient doesn't arrange to receive them, the FDs will be discarded and closed automatically by the OS. Whereas, if we are sending separate one-byte messages, the recipient needs to know what to do with those.

This is redundant as the destructor already uses a recoverable assertion, which will not throw during unwind.

I have long assumed AutoCloseFd wrapped only an integer and was shocked to realize it was more that that...

Fix #800 : pwritev() missing before Android API Level 24.

Update link to @popham plugin

Fix typo

Add HttpClient wrapper for limiting concurrent connections

Feature grab bag

Not sure how this slipped by for so long!

This class lets you hold a temporary value that is only safe to access under lock, while you release the lock to do some other work.

Jlee/fix mingw warnings

http-test: Replace windows-conditional block with extra poll

Seems to work reliably under Windows, hopefully also Mac.  I'm not
totally sure why the extra polling is necessary, though.

`Maybe<T>(Maybe<T&>&&)` should do a copy, not a move.

`Maybe<T&>` does not own the `T` it points to. But, before this change, initializing a `Maybe<T>` from a `Maybe<T&>` would inadvertently perform a move, stealing the `T` away from its owner.