add support for resizable ring

Allows the ring to be resized as a cluster operation similar to join/leave.
Expansion is only allowed, but the restriction is temprorary, and shrinking
requires only small modifications.

When the operation is staged/commited the claimant calulates a resized ring,
running it through claim. It then schedules a "resize operation" for each
partition, via the next list. Each partition is scheduled for the operation because
during resize, each index potentially has data to send to others. Per partition,
the resize operation consists of several "resize transfers", each of which must be
completed to complete the entire operation. The first of these resize transfers is
scheduled by the claimant. Subsequent transfers are scheduled by the vnode that
owns the partition. When all of the transfers for a partition of have completed,
the operation is marked as such in the next list. Once the operation has completed
for *all* partitions the claimant installs the resized ring.

The handoff subsystem has been modified to add a new transfer type: resize_transfer.
In addition, the handoff sender now supports applying a function to keys that are
not sent (due to the handoff filter). The function operates on the unsent key and
a per-sender defined accumulator. Resize transfers are triggered like hinted and
ownership handoff by the vnode manager and vnode. The primary difference between
those transfers and a resize_transfer is that the latter includes a filter
that only sends keys between the source and target partitions if, for both, the
key hashes to the same position in the preflist. Resize transfers also include an
unsent keys function and accumulator that determines which partitions the key
would be destined for. The vnode uses this information to schedule its subsequent
resize transfers. A partition which has not been transferred to yet and is in the
returned list will be scheduled. No more resize transfers will be schedueld when
the returned list contains no partitions or only partitions that have already been
scheduled.

One major difference between typical transfers and a resize operation is the partition
does not delete its data (or unregister) after completing. For some partitions, they will
remain running but a portion of their data should be removed. Other partitions will no
longer live on their original owner should have all of their data deleted. This is
not addressed in this commit.

During resizing, how vnodes forward has been modified, as well. Like regular handoff
forwarding is performed both explicitly (when the vnode returns {forward,...} from
handle_handoff_command) and implicitly (after a transfer has completed). The difference
is that since the operation consists of multiple transfers, messages can be implicitly
and explcitly forwarded at the same time. Messages whose "hash" map to a portion of
the keyspace already transferred as part of the operation will be implicitly forwarded.
Messages whose "hash" map to a portion of the keyspace not yet transferred can be
explicitly forwarded. To determine the hash of the request, a new vnode callback has
been added: request_hash. This callback is optional, unless the application supports
dynamic ring. The callback can also return undefined instead of a hash. In which case,
the message will be handled locally and not forwarded implicitly. Special care must also
be taken to handle messages on a vnode forwarded from another, because primaries take part
in forwarding during resize. Coverage requests are not forwarded during a resize.
begin cleanup after resized ring

After a ring resizes there are several cleanup operations that must
be performed. In some cases a partition no longer exists (if the ring
shrinks) or its owner has been moved to another node. In these cases the
vnode must be unregistered and all its data deleted. In other cases, where
the vnode does continue to exist and has not moved, some data must be removed
but the vnode continues to run. This commit addresses the former.

After completion, the resized ring will have deletions scheduled for the
appropriate indexes. The deletions are scheduled like any other ring transition.
Although this is considered part of the resize operation, at this time the
future ring has been installed and the vnodes targetted for cleanup appear as fallbacks.
After each deletion is complete, the vnode unregisters. After all deletions are
complete the full resize operation is considered complete.
ability to shrink ring

not many changes were necessary with the exception that when the ring shrinks
some indexes disappear, which needs to be handled specially. Note: this only works
assuming NewRingSize < MaxN, where MaxN is the largest N value used on any bucket
in the cluster
prevent staging resize when not all nodes support it
update console output to account for changing ring size
reduce impact on gossip during resize using 'set_only'
support for when SHTF during ring resize

allow ring resize operation to be aborted. The operation is staged like
any other cluster op. The abort will only be staged/performed if the
operation is in the process of performing resize transfers (resized ring
has not been installed). Otherwise, there is nothing to abort, so
the operation is ignored.

Support force-replace during resize. Works like force-replace during
typical cluster operations. Transfers are rescheduled on the replacing
node under the assumption that the replacing node may have been rebuilt
from a recent backup.

force-remove is not supported because it may end up causing too
many transfers to be rescheduled on the remaining nodes, overloading
them. Instead force-remove is supported by performing an abort
of the resize operation first.
move mgmt of new vnode proxies during resize to ring handler

also add stopping of extra proxies abandoned during an abort
of a resize or a completed shrinking of the ring
honor forced_ownership_handoff for resize operations

ensures that at most forced_ownership_handoff vnodes will be performing
resize transfers accross the cluster at once

also, the previous code was just wrong