MB-5307: unbreak cli ebucketmigrator

Change-Id: Ie9e09ac62085cc9ffee4cb807a90d34fe63cdf1e
Reviewed-on: http://review.couchbase.org/16767
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
MB-5307:ebucketmigrator:dont ask password when not given username

Change-Id: I4156d2be4314f553e74e80e56b185ccc39a61f1b
Reviewed-on: http://review.couchbase.org/16768
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
MB-5307: made ns_vbm_sup:apply_changes only touch affected nodes

Previously it would go find children list on all nodes, apply changes
and do set replicas call with big list of mostly same replicas.

Change-Id: Id7430e44abf30ffbf32ddec37cd8b016a95bc8a7
Reviewed-on: http://review.couchbase.org/16769
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
MB-5307: support slow network simulation for cluster_run

This is quite obviously linux-only. And requires quite recent iproute
tools and reasonably recent kernel.

First part of commit allows ./cluster_run to prepend something to
arglist.

This allows for command lines like this:

./cluster_run -n4 --prepend-extras ./scripts/run_in_ns.rb

Second part is run_in_ns script. Which sets up VDE networking with
round-trip delay around 2.4 milliseconds from host to host and
bandwidth limit of 30 megabytes per second. It spawns nodes inside
newly created network namespaces which makes kernel use "full" routing
between erlang nodes (and memcacheds). netns per node also makes
running per-port-moxi possible as netns-es don't intersect
w.r.t. bound ports even on 0.0.0.0.

Change-Id: I5a6d435565c280592ba7a2da2c4837dbddcb52d6
Reviewed-on: http://review.couchbase.org/16770
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
MB-5307: dont hibernate gen_events

Which seems to have negative effect on performance during rebalance,
where we're changing vbucket map quite a lot.

Change-Id: I866ee10eecdfab9f67601e02b7bb1b2a1ff944d0
Reviewed-on: http://review.couchbase.org/16771
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
MB-5307: menelaus_web:handle_streaming now eats all notifications

I've noticed positive effect on CPU during rebalance because we have
significant amount of config change due to vbucket map updates. And it
makes sense to consume batch of changes before sending out updated
stuff.

Change-Id: If4e85f6d25367283226534c6e190030d7e1865e9
Reviewed-on: http://review.couchbase.org/16773
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>
MB-5307: don't compute saslBucketsStreaming twice on each update

menelaus_web:handle_streaming is calling streaming function twice per
iteration. Once with 'stable' argument and second time with
'normal'. This is done in order to remove 'volatile' fields from value
that's used to decide if change needs to be streamed. But
saslBucketsStreaming doesn't have difference for stable and normal
responses.

So new rule is if 'stable' invocation returns {just_write, JSON} we'll
use JSON without calling streaming function second time. And
saslBucketsStreaming is now using it.

Change-Id: I08aa427b1e34d3d1d6ec84c50ffa7886c1a1c83b
Reviewed-on: http://review.couchbase.org/16774
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Artamonau <aliaksiej.artamonau@gmail.com>