Reject concurrent configuration changes

[kuujo]

This PR fixes #26. Both JoinRequests and LeaveRequests received by the leader will be rejected if the leader is already in the process of committing another configuration. The ServerStates join() and leave() methods will retry configuration changes indefinitely if a leader responds with a null error response (not very elegant but works until better server-side exceptions are added).

§4.1

[kuujo]

Actually, this safety constraint is most essential when the quorum of voting members changes, which is when a member is promoted from PASSIVE to ACTIVE or removed from the cluster. I'll opt to keep the configuring flag in all cases of configuration changes just to be safe, but I don't think it's actually necessary when adding a server to the PASSIVE members list since the quorum does not change.

[kuujo]

Okay, this PR was updated to include checks to ensure promoting members from PASSIVE to ACTIVE is done safely as well. Essentially, when a configuration change is started, the index of the configuration entry is stored in the LeadsrState. If another configuration change is requested while configuring is non-zero, it will be rejected. Storing the configuration entry index allows that index's CompletaeFuture to be referenced to wait for a configuration change to be completed for promoting members.