Cluster Metadata: The Basics

This commit implements the basic moving parts for riak_core's new k/v
store for cluster-wide information. Cluster Metadata is meant to
replace current uses for metadata stored in `riak_core_ring`.

The interface for interacting with the store is defined in
`riak_core_metadata`. Data is read and written locally and is fully
replicated to all nodes eventually. Data is stored on disk using dets
and is managed by `riak_core_metadata_manager` (the ground work has
also been laid to keep a copy of data in-memory w/ ets for use on
reads). Data is addressed by a given prefix (a two-tuple of any erlang
terms) and a key. Each stored prefix/key has an associated logical
clock (a dvvset -- more below). The representation of the object and
its clock are abstracted via `riak_core_metadata_object`.
`riak_core_broadcast` implements a new broadcast/gossip protocol for
disseminating updates to other nodes. The module is implemented to be
a general broadcast protocol that could be used by other
subsystems. `riak_core_broadcast_handler` is a new behaviour that
defines the API a module must implement to use
`riak_core_broadcast`. `riak_core_metadata_manager` implements this
behaviour. `riak_core_broadcast` is based off the plumtree protocol
(http://www.gsd.inesc-id.pt/~jleitao/pdf/srds07-leitao.pdf) with some
modifications to make it more partition tolerant and fit with
riak_core's membership model. The implementation uses the sender-based
tree approach mentioned but not analyzed in the paper. The current
implementation does not fully guaruntee at-least once delivery (it
will be fully implemented in a future commit).

`riak_core_broadcast` and `riak_core_metadata_manager` run per node
and are started after the ring manager.

This commit introduces dvvset.erl from
https://github.com/ricardobcl/riak_core/blob/dvvset/src/dvvset.erl. This
may not be the actual version of Dynamic Version Vectors
used. `riak_core_metadata_object` is meant to abstract the object
representation and logical clock so a switch to a new implementation
of dvvset or one just using vector clocks can be made easily.
Improve Cluster Metadata Storage

* move to using a dets file per prefix/subprefix
* store data in ets table per prefix/subprefix. read from ets
* restricts prefix/subprefix to binaries
Basic Iterators for Cluster Metadata

Allows iteration and folding over all keys stored under a
prefix/subprefix
Further Cluster Metadata Storage Improvements

* MD5 prefixes for use in filenames. Raw binaries are unsafe and
  difficult to parse.
* Store metadata in in a manifest file. Folding over files in a directory
  to determine existing data is unsafe, error prone, and stupid.
* Re-allow prefixes to contain atoms. To prevent collision between binaries
  and atoms a filename trailer is appended.
* Sync all dets writes to disk so we don't easily lose data on emulator crash"".
Fix Cluster Metadata Conflict Resolution

* pass proper arity function to dvvset:reconcile/2
* timestamp resolved value
Add Optional Conflict Resolution to Metadata Iterators

* When resolution is used, iterators are "single-use".
The iterator functions aren't pure in this case. If no resolution option
is provided then this resriction does not apply
* Resolution can be done via function or lww like get/3
Allow Conflict Resolution on Metadata Write

extend riak_core_metadata_object:modify/4 to take a
resolution function (it differs from resolve/2, see edoc).
Add Conflict Resolution in Metadata Folds

using the existing support in iterators
Add Logical Deletion to Cluster Metadata

* similar to ring metadata
* write tombstone values on delete
* handle tombstones on read
* resolvers and modifiers must be tombstone-aware. see typespecs.
* iterators/folds can optionally return the tombstone value or can provide
a default value to return or function to apply when they are encountered
Iterate only a Subset of Cluster Metadata Keys

If keys are tuples then a match-spec like pattern
can be passed as an option to iterator/2 and fold/4 to
filter which keys the iterator visits.
Support both new and old-style crypto MD5 functions.
move ring update logic into broadcast process

this avoids several unnecessary messsages and makes things cleaner
as pointed out in review.

In addition, change all_broadcast_members/1 to use riak_core_ring:all_members/1
since they are equivalent.
add configurable timeouts to calls in riak_core_broadcast

the calls are primarly used for debugging (primarly in a live system)
so making the timeouts configurable seemed like the best idea. The original
functions default to 'infinity'.
fix typespec for broadcast_handler:graft/1
change all metadata manager calls to use infinite timeout
Merge pull request #363 from basho/jrw-cluster-meta

Cluster Metadata (Part 1/2)