Dynamic backend service discovery

Nobody has claimed this yet.

(from chat)

Possible working path:
* modify L402 to not read the services from disk anymore (well have the option, but a new interface), instead it accesses etcd to get the current working config set
* there's an entry for each service it proxies to (key hierachy ofc flexible), it then watches those key sets for changes, when they change it updates its in-memory forwarding/service table
* we have the normal 3f+1 instance of the naut server itself active
* upon start up, they each attempt to grab win the election by grabbing the underlying mutex w/ a lease (https://godoc.org/github.com/coreos/etcd/clientv3/concurrency#Election)
* the leader then sets a bit in their etcd service discovery config, which updates the L402 proxy to direct traffic as needed
* anytime they instance die or become unavailable (fail the hearbeat, or their lease expires), then the election restarts

docs on their election API: https://github.com/etcd-io/etcd/blob/master/Documentation/dev-guide/api_concurrency_reference_v3.md

Start by locating L402 and read the etcd v3 concurrency election API documentation linked in the issue. The proposed work involves replacing or extending disk-based service configuration with etcd-backed discovery, watches, in-memory updates, and leader election; done would require agreement on the interface and behavior for startup, changes, and lease or heartbeat failure.

Written by the indexing model from the issue text.