adding LocalAuthority as an option for a client-server model

[rrichardson]

This is a proposal for how to manage configuring a client with the static address of a server. It builds, but I haven't tested it. I want to make sure this is a sane approach before I go further.

I had to create a run() function so that I could statically dispatch based on the type of Authority. I was unable to Box SyncControllerHandle without editing the noria code.

[jonhoo]

These should probably also be added to the zk_addr argument

[jonhoo]

Ah, that's an interesting to this. I'm a little worried about constructing a LocalAuthority this way, since it's not intended to be used in this fashion. Its impl Authority assumes that everyone shares the same LocalAuthority instance. In this particular case, it doesn't matter too much, since the client doesn't actually use the Authority part for anything except "discovering" the leader, but it's definitely an abuse of the API that might bite us later. I wonder whether a better approach here would be to write a new type, DirectClientAuthority, which implements Authority but is constructed by giving a controller address, yields that address when asked, and apart from that returns panic!("DirectClientAuthority can only be used by Noria clients, not by workers").

[rrichardson]

@jonhoo - I agree that using LocalAuthority in this way is an abuse. It was suggested in the ticket that there be a ConfigAuthority which makes a bit of sense.. it would be a read-only authority.

What about breaking the Authority trait into two traits:

1. An "authority" (Readable) portion.
2. A "collaborator" portion.. involving the elections and consensus.

So the ZookeeperAuthority struct would actually implement both, but the ConfigAuthority would only implement the read portion (being directly initialized with a Map of some sort )

[jonhoo]

Sure, that seems like a reasonable way to do it. Maybe Discover (for finding the controller) and Participate (for becoming a worker)?