MB-10515: made 2.5.1 nodes take over mastership over 2.5.0 nodes

I.e. in order for MB-10220 fixes to be effective.

Change-Id: Ic74bd90cd5e8d7f0edb1e7386c06baad898440b2
Reviewed-on: http://review.couchbase.org/34729
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
bp:MB-10051: configurable disk and metadata limits

Change-Id: Icfdd2e580149e54b9627b2da460407eae0a8285b
Orig-Author: Brent Woodruff <brent@fprimex.com>
Orig-Reviewed-on: http://review.couchbase.org/34265
Reviewed-on: http://review.couchbase.org/34742
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
CBSE-1238: introduced anticipatory mccouch delay

So that we can optionally slow down persistence and lower IO
contention. Hopefully allowing more efficient and quicker compaction.

Change-Id: I3c7cc520d4068d4445c6ff307608fff0510bf04e
MB-11825: ignore unexpected infos in new_ns_replicas_builder

Change-Id: Ib0e2e8abf44510b0dd62f96b05ee5cbcb581b95e
Reviewed-on: http://review.couchbase.org/39908
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
MB-10437: prefer oldest waiter in concurrency_throttle

Old behavior could choose same pid(s) over and over again. Which
caused particular problem for initial replication under slight udpates
load. I.e. it would repeatedly pick already mostly up-to-date vbuckets
over vbuckets that still need to be replicated. Which would cause very
short batches which in turn would cause very slow rebalance.

By picking oldest waiter (modulo system clock jumps which should be
infrequent) we avoid this problem. It should also help at least
somewhat for the case of ongoing replication under somewhat heavy but
not too heavy load, due to better avoidance of too short replication
batches.

Change-Id: Id9fc64ee08b77f6a93760f8c4de237f14fe5ebd9
Reviewed-on: http://review.couchbase.org/38368
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>