DHCP and DHCPv6 support (and discussion)

Right now ZeroTier networks can use DHCP, but it requires a lot of manual config and few people use it. ZeroTier's internal IP management is simpler but obviously a lot more limited than a full-blown DHCP server.

Properly supporting DHCP is complex and will probably require that we write (or adapt) a DHCP filter/parser or possibly even a full blown DHCP client.

Some of the issues are:

1. DHCP is absolutely NOT secure if accepted from an un-trusted source. Joining a network should NOT engage DHCP on the interface by default, ever, without the user approving it. Right now ZT explicitly turns DHCP client functionality off to prevent this. DHCP can be used to push all kinds of config to clients which many will blindly accept-- everything from DNS to Windows domain info to routes.
2. We're currently working on #178 ("full tunnel" in VPN parlance) to allow ZeroTier networks to easily be assigned default gateway status without disrupting ZT P2P traffic. This is also dangerous, so we will not permit a network to set a default gateway without explicit user approval. Otherwise randomly joining a network would allow that network to grab and redirect all your traffic. If DHCP is supported we will have to merge these two functions somehow since extra steps are required to support default gateway, such as by sniffing DHCP and engaging our default gateway trap door routes when DHCP pushes a default gateway. Fun fun fun.
3. It might be useful to users to support a "safe mode" DHCP. This would use a built-in DHCP client instead of your OS'es and would only allow the setting of interface IPs. All other DHCP options would be ignored. This would let you join and get an IP on DHCP managed networks without letting them reconfigure your entire networking environment.

This is kind of a big ticket and is dependent on #178. We will do default gateway / full tunnel first, probably in 1.1.6, and then do this at some point in the future.

One final DHCP issue:

DHCP hosts should be flagged as Ethernet bridges even if they don't bridge anything. In addition to being a permission (for security reasons), the Ethernet bridge flag exempts hosts from the multicast limit. On large networks DHCP could start failing if the number of clients exceeds the multicast limit, but if the DHCP server is flagged as a bridge this won't happen. This is a UI issue on the controller and a documentation issue but I wanted to mention it here.

Start by reading the dependency on #178 and the security constraints described in this issue. The work is not ready for a newcomer until the DHCP approach, approval flow, safe-mode behavior, default-gateway handling, and controller UI or documentation changes are decided and their implementation points are identified.