CCBC-420: vbucket: don't remap to soon-to-be-removed nodes

See the bug and the linked MB issue for more details. In summary, during
a rebalance-out where nodes are being removed, the node's memcached
process will remain active accepting connections and commands but
responding to them with not-my-vbucket replies. The goal for this grace
period is to allow for a graceful remapping of items to the new master
node.

This behavior itself relies on the fact that the given node shall only
respond for _existing_ commands mapped to it before (or around) the
start of the grace period, but that no _new_ commands should be sent to
it during said period.

The means to determine if a node is in such a "Eject Wait" state (as
I'll call it here) is to check whether it has any vbuckets assigned to
it. If the node has no vbuckets assigned to its index then we should
assume that it will soon disappear. Implemented here, the number of
vbuckets a node is assigned to is the sum total of any vbucket in both
the vBucketMap and the vBucketMapForward arrays which contains the index
of the given node in its list.

The found_incorrect_master() function's purpose is to pick a node at
random (or slightly more predictable than 'random') where a command
should be forwarded to assuming that the current mapped node returns a
not-my-vbucket. In this commit I've tried to ensure that the new node
should only be one which retains vbuckets.

Change-Id: Ib8017ea07a38c2479deebcb532af131ec2150942
Reviewed-on: http://review.couchbase.org/37322
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Matt Ingenthron <matt@couchbase.com>
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
Reviewed-by: Brett Lawson <brett19@gmail.com>