Fix view transition corner case

Prior to this commit, a newly established leader would set view_vsn to
{Epoch, 0}. However, this could lead to the same view_vsn being used
twice for two different views. Specifically, if the leader changes
while there is an outstanding joint view, the new leader could report
the joint view to the ensemble manager with a vsn of {Epoch,0} as well
as report the transitioned view on the next tick with the same vsn.

This commit changes the leader to use {Epoch,-1} for the view_vsn when
newly established, which will always be less than the {Epoch,0} vsn
that could potentially be used to commit the view transition on the
next tick.
Finish implementing peer syncing behavior

This commit completes the peer syncing logic that was only partially
implemented prior. The purpose of the syncing logic is to repair
corrupted/missing backend data. In particular, the goal is to address
silent data corruption. Just because data was previously written to a
given backend does not mean the data has not since been silently lost.

The backend behavior is responsible for informing riak_ensemble if
the backend data can be trusted or not via the trusted/1 callback.

An untrusted peer only becomes trusted after syncing with a majority
of other peers. Since the untrusted peer itself cannot be part of this
majority, the presence of an untrusted peer requires more nodes to be
available than the traditional simple quorum used for consensus.

For example, for a 3-node ensemble, all 3 nodes must be available if
any one of them is untrusted. If even 1 node is offline, the ensemble
will be unavailable.

This behavior is therefore similar to the stronger constraints required
to protect against byzantine faults.

The actual syncing logic is implemented as follows.

An untrusted peer first tries to contact a quorum of trusted sibling
peers. If a quorum of responses is received, the peer moves to the
syncing state and invokes the appropriate sync callbacks.

The backend is responsible for implementing the actual syncing logic
and ensuring that the peer successfully syncs with a majority of
peers. The backend then returns the list of successful syncing peers
as part of the sync_complete message. The peer logic then verifies
that these peers are still trusted. If not, the sync is considered
incomplete.

If a peer is unable to sync with a majority of trusted peers, then the
peer attempts to sync with all peers -- trusted or otherwise. This is
necessary in cases where a majority of peers are untrusted. This
all-sync logic only succeeds if all peers are up. Given this constraint,
this approach is safe (despite syncing with other untrusted peers) as
long as a '2f+1' size ensemble has had fewer than 'f' true failures. As
a paxos-based protocol, riak_ensemble is already required to have fewer
than 'f' failures at any time.  Thus, this all-sync assumption is no
stricter.
Fix type specs for riak_ensemble_msg:quorum_met
Merge pull-request #14 from jdb-ensemble-sync

Conflicts:
	src/riak_ensemble_msg.erl