Remove joint consensus (ProposedMembers) support.

This was present in the original raft paper but was removed from the final
thesis because simpler protections suffice as long as only one node is added
or removed at a time.

Use the term "observer" consistently for non-voting members.

@spencerkimball 
Sounds good.


On Wed, Sep 10, 2014 at 12:50 PM, Ben Darnell <notifications@github.com>
wrote:

> In multiraft/multiraft.go:
>
> > @@ -517,6 +506,8 @@ func (s *state) submitCommand(op *submitCommandOp) {
> >
> >  func (s *state) changeGroupMembership(op *changeGroupMembershipOp) {
> >  	log.V(6).Infof("node %v proposing membership change to group %v", s.nodeID, op.groupID)
> > +	// TODO(bdarnell): update currentMembers.  Should we disallow more than one
> > +	// membership change in flight at a time, and if so how?
>
> The tricky part is that this means the result of a changeGroupMembership
> would be dependent on whether the node perceives the previous membership
> change as being committed, and this raises questions around idempotence
> (immediately after an election the new leader may not know the current
> commit position, although we are planning to wait for things to catch up in
> most cases for other reasons).
>
> This may be moot - I think if we only look ahead one log entry at a time
> (instead of the entire uncommitted tail), we'll be fine even if there are
> multiple pending membership changes at a time. This also alleviates some of
> the problems with rollbacks that I had raised on the mailing list earlier.
> I'm going to explore this refactoring in my next change. It'll be
> theoretically less efficient (currently it's cheap for a large chunk of the
> log to become committed at once), but there really shouldn't be more than a
> few uncommitted entries outstanding at a time.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/cockroachdb/cockroach/pull/47/files#r17384184>.
>