runtime: initial support for direct udp connections

[npry]

2(.5) new actors: path discoverer (the .5 is its per-peer supervised children) and direct udp. Recommend reviewing commit-by-commit.

The direct udp actor is basically plumbing between the dataplane queues and two udp sockets (one IPv4 and one IPv6 (if available)) -- it mostly just shuttles packets back and forth from the socket to the queue. Since it's the only part of the system that knows the UDP local ports, it's also responsible for publishing the fully resolved local endpoints on the bus (it listens to netmon for the set of locally bound addresses, combines with the port, and merges in the IPv4 stun address verbatim). The control actor grabs those and reports them up, and the pd actor also uses them to construct its CallMeMaybe. I actually totally skipped the underlay transport trait here. I think for modularity, it's probably preferable to use the trait, but it really also felt fine just to plumb it in directly. It just doesn't feel like there's actually that much to it, and we currently don't have a "transport registry" of any description because the transports are all connected through channels instead, and have kind of bespoke shapes anyway. To revisit -- I don't think this should block this PR.

The path discoverer actor tracks the ActivePeers set introduced in #312, and in a similar structure as multiderp, spawns a supervised child actor per active peer. Each of these PeerPd children is responsible for running a periodic CallMeMaybe + Ping probe and noting which paths come back with Pongs from the peer, and with what latency. The best path is chosen and published back to the parent, which aggregates a map of PeerId -> DynEndpoint (best paths) over time, which gets published to the bus. The route updater is updated to merge in this new best path information. Currently this is strictly preferred over derp, even if in reality derp would have a shorter latency (derp paths aren't pinged currently, just used for CallMeMaybe) -- derp is only used if there is no UDP path for the peer at all. We do it this way just because the derp latency isn't immediately accessible to the route updater -- it could listen for the derp latency map and reconcile this against the peer's derp region, but this will be much simpler to do with the kv store and feels like an edge case, so I left it out for now.