Adds in-place manual recovery support.

[slackpad]

This adds several important capabilities to help in upgrading to the new Raft protocol version:

1. We can migrate an existing peers.json file, which is basically the source of truth for the old version of the library before this support was moved to be fully in snapshots + raft log as the official source.
2. If we are using protocol version 0 where we don't support server IDs, operators can continue to use peers.json as an interface to manually recover from a loss of quorum.
3. We left ourselves open for a more full-featured recovery manager by giving a new RecoverCluster interface access to a complete Configuration object to consume. This will allow us to manually pick which server is a voter for manual elections (set 1 to a voter and the rest to nonvoters, the 1 voter will elect itself), as well as basically any other configuration we want to set.

This is based on the branch in #139.

[slackpad]

/cc @ongardie and @sean- to take a look.

[slackpad]

Thinking through how I did RecoverCluster() by adding the new log entry in the same term as the last log entry. This seems safe because if you apply it on all the servers and they all had the same term, then any server with a higher index who should win the election will still have higher index after this operation. If you look back in commits here, I originally didn't mess with the log at all, but there were too many edge cases to manage if the server sent a snapshot with the older configuration, so this seemed like the cleanest solution. Need to make sure this is safe in all cases, though.

[ongardie-sfdc]

Why would you ever want to bootstrap a new cluster with version 0?

[slackpad]

During the phase where we are transitioning to protocol version 1 but have set it to 0, we may not want to have this new entry in the log in case an older server joins, since we are saying if protocol version == 0 that we are compatible with old servers.

[ongardie-sfdc]

We can migrate an existing peers.json file, which is basically the source of truth for the old version of the library before this support was moved to be fully in snapshots + raft log as the official source.

I think @superfell and I had convinced ourselves that a running cluster would have the same information in its snapshot or log already, so we wouldn't need to ever read peers.json again. Was that just wishful thinking? :)

Thinking through how I did RecoverCluster() by adding the new log entry in the same term as the last log entry. This seems safe

Assuming all the servers go through this procedure, the set of servers that are eligible to become leader would stay the same. So that's good. But I'm gonna need to think about this.

[slackpad]

I think since peer changes used to be stored in the log and snapshots so we could probably just delete peers.json in almost all cases and things would work fine. Consul had some places where it would manipulate this at startup, and if it's there it could also mean that the operator wants to mess with it so I'm planning in Consul to ingest it and then blow it away. I think for most normal use cases we could just delete it and things would work fine. I should put "truth" in quotes :-)