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
MB-100: removed unused ns_watchdog and cucumberl

Change-Id: I2bdfcbf1b53b4410912f6ec93a2e16ad48683b0e
MB-100: implemented quicker way of grabbing vbucket db infos

Change-Id: I5f21315d6f287508e0e2925db488dad1245be592
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
MB-100: hibernate ns_config_log

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

Change-Id: I84b91f6f6586eb6a63cfa49a4d3ff299383fd36e
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
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
MB-8032: stop unwanted replications before setting vbucket states

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

Change-Id: Iff6583ae97fbb252806310fd753c2ac2fb9a2761
MB-100: fixed indentation

Change-Id: I46a6300a464fcb4aa4ba119d7f555088a2c1d723
MB-100: sync babysitter logs before dying

Change-Id: Ic8dcb7888fa5a160e5d3ec0498590b92e6a20e4e
MB-100: correctly treat empty crash log as empty queue

I.e. not empty list which causes ns_crash_log to die.

Change-Id: I7248ca04afa929f3591ca0029667bf01a5b4e163
MB-100: save crash log atomically

My initial thinking was to avoid fsync at expense of potentially
losing this information (which can be lost anyways due to
non-durability of our various logs including ns_log).

But given I've seen how it can really easily cause empty file I've
changed my mind. So we're doing save-to-temp-then-sync-then-rename
procedure.

Change-Id: I24a44a117c469d90b8240bf20fecc05ce4610084
MB-100: batch all outstanding crashes before saving them

I.e. if we have sudden herd of crashes, old could would save it one by
one. Potentially not coping with incoming crashes traffic.

New code implements simple trick of postponing actual saving until all
currently enqueued messages are processed.

Change-Id: I5ef4408ece05f75bb05416b160eab8dda38b40e6