Make ensemble manager only save state if changed

This commit optimizes the ensemble manager to only save its state if
the existing saved state does not already match the new state. This
optimization is already used by ensemble peers and has shown to
significantly reduce disk write traffic.
Implement central storage manager

This commit adds a central storage manager to riak_ensemble. Previously,
individual ensembles as well as the ensemble manager would independently
save their own state to disk. However, such an approach scaled poorly as
the number of independent ensembles increased. It was not uncommon to
see thousands of synchronous writes/s issued to disk, overwhelming the
I/O subsystem. To solve this issue, the storage manager was created.

Rather than storing data independently, the storage manager combines the
state from multiple ensembles as well as the ensemble manager into a
single entity that is stored together in a single file. Since this file
is now a critical single point of failure, the storage manager uses newly
added logic, implemented in the riak_ensemble_save module, to save four
redundant copies of the data to disk.

The manager is also responsible for coalescing multiple writes together
to reduce disk traffic. Individual writes are staged in an ETS table and
then flushed to disk after a delay (eg. 50ms).

The storage manager supports both synchronous and asynchronous writes.
Ensemble peers use synchronous writes, while the ensemble manager uses
asynchronous writes (since the manager reflects state that can easily
be recovered from other managers / the root leader).
Add backpressure to periodic messages

By design, ensemble leaders periodically send messages to both the root
leader as well the local ensemble manager. However, when there are many
independent ensembles, these periodic messages can easily overwhelm the
target process leading to ever growing message queues.

This commit address this problem. First, ensemble leaders no longer send
periodic messages to the root leader. This prevents the root leader from
being overwhelmed. Instead, ensemble peers directly send update_ensemble
messages to their local ensemble manager. This change has been deemed
correct, as the root leader was simply used for serialization and
further consideration shows this serialization is unnecessary.

Second, to avoid overwhelming the ensemble manager, backpressure has
been added to the messages (update_ensemble, gossip) sent to the
manager. This backpressure has been added by changing the appropriate
messages from casts to calls. Likewise, to avoid blocking the sending
process, the sender now spawns a singleton helper process that blocks on
the relevant calls. This design provides non-blocking messaging while
still providing backpressure.
Prevent peer initialization from blocking peer sup

Prior to this commit, riak_ensemble_peer:init could block while reading
the saved fact from disk. This would result in the peer supervisor
blocking when starting a new peer. Since other components are designed
assuming the peer supervisor is always quick to respond, this blocking
could cascade causing other process to block as well, resulting in large
message queues.

This commit changes riak_ensemble_peer so that only minor initialization
is done in init, with the remaining work handled in a newly added setup
state.
Optimize ensemble manager orddict:from_list usage

The use of orddict:from_list by the ensemble manager becomes a
bottleneck when there are a large number of ensembles. This commit
addresses this by instead using lists:ukeysort which is equivalent in
this scenario yet considerably faster.

From a simple microbenchmark:
  length   orddict:from_list   lists:ukeysort
   100      139                 34
   1000     11973               463
   10000    1241925             6514
Increase ensemble tick from 200ms to 500ms

This commit slightly increases the ensemble tick rate in order to
decrease the commit frequency and reduce load when using a large
number of ensembles.
Add rebar and fix how $(REBAR) is set in Makefile

Do not search for rebar in path in Makefile
Remove commented-out code from ensemble manager
Merge pull request #21 from basho/bugfix/optimize-many-ensembles

Optimize handling of large ensemble count

Reviewed-by: andrewjstone
Add test for dataloss while trusting pending peers

This test will fail when we automatically trust pending peers.
This allows us to reach a new quorum of peers that don't contain data,
because we aren't syncing when pending peers startup. This can result in
existing data being returned as `notfound`. Fixing this failing test
requires syncing data before transitioning to the final view.

Test for #17
Remove pending state from riak_ensemble_peer

The pending state allows pending peers to act trusted, when they
shouldn't be. It is also unnecessary. Removal of the pending state makes
pending_dataloss_test.erl pass and completes #17.

Pending views are only needed to ensure propogation of views so that
peers may be started dynamically on remote nodes before the leader
transitions to using them. If the leader tried to use the peers before
they were up, he would lose leadership and the peers may never be
started because they require propogation to the manager from the leader
to start them.  Therefore pending views were introduced to help ensure
those peers were started and stable leadership was maintained. However,
once those peers are started they are just normal peers and don't need
to do anything special outside the protocol. Therefore there is no need
for a separate pending state.

A better description by @jtuple is in this comment:
https://github.com/basho/riak_ensemble/commit/01dda5a2d1e0fa56a8096eacc7a1c9495d3bce34#commitcomment-5888125
A statem test for riak_ensemble_client API
fix is_missing to understand partial failure
parallelize ensemble_only_test
fix postcondition for kget notfound
change timeout for slow builders in test
add lager to applications deps in app.src
use ports to launch erlang VMs instead of os:cmd
WIP - add some logging/exit handling