MB-100: use much larger chunk in misc:raw_read_file

I don't know how I missed it but clearly reading 10 bytes at a time
is silly.

Change-Id: I346fc5394f691ea0cf3f562f135a9cc93ecfab69
Reviewed-on: http://review.couchbase.org/25503
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-100: removed unused ns_watchdog and cucumberl

Change-Id: I2bdfcbf1b53b4410912f6ec93a2e16ad48683b0e
Reviewed-on: http://review.couchbase.org/25504
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-100: implemented quicker way of grabbing vbucket db infos

Change-Id: I5f21315d6f287508e0e2925db488dad1245be592
Reviewed-on: http://review.couchbase.org/25505
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-100: slashed CPU consumption of timer

I've found stdlib's timer to burn CPU without good reason. Here's what
happens.

The problem is that it sleeps in milliseconds but computes time in
microseconds. So there's simple and I'd say somewhat funny bug in code
to compute milliseconds to sleep. They compute microseconds difference
between now and nearest timer event and then do _truncating_ division
by 1000. So on average they sleep 500 microseconds _less than
needed_. On wakeup they check do I have timer tick that already
occurred? No. Ok how much I need to sleep ? They do that bad
computation again and get 0 milliseconds. So next gen_server timeout
happens right away only to find we're still before closest timer tick
and to decide to sleep 0 milliseconds again. And again and again.

This change adds fork of timer that keeps track of time in
milliseconds. The idea is given all intervals and sleep durations are
in milliseconds anyways, there's no benefit at all keeping tack of
time in microseconds.

Rest of change replaces all occurences of timer:xxx_interval and
timer:xxx_after with same calls to timer2 module.

Change-Id: I469a136001fb314559a733acf0a80b598a74c194
Reviewed-on: http://review.couchbase.org/25506
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-100: hibernate ns_config_log

Because it appears to be one of largest heap consumers based on etop
data.

Change-Id: I84b91f6f6586eb6a63cfa49a4d3ff299383fd36e
Reviewed-on: http://review.couchbase.org/25524
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-100:ale: really silence default error_logger

I.e. if we don't do that we'll see tons of ugly crash reports on
stdout.

Change-Id: Ibcec72de374e1dce4919b5c51e97a17927b90ef3
Reviewed-on: http://review.couchbase.org/25525
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-100: correctly categorize tap replication changes

I.e. old code actually tried to change vbucket filters of
replications that are just created or dropped

Change-Id: I51bd3a71d448a2479bcdc0dedf9f4967abef093f
Reviewed-on: http://review.couchbase.org/25526
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-8032: stop unwanted replications before setting vbucket states

I.e. so that situations like replication into activated vbucket are
impossible.

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