This reverts commit 46de1482.
Not supported on CC7..

Just found out we can use atomics with shared pointers, neat
http://en.cppreference.com/w/cpp/memory/shared_ptr/atomic

Thanks to Elvin Sindrilaru for the bug report

After accumulating several billions of writes in a single run
on EOSPPS, a QDB node restart took several minutes.. This should
fix it.

This value is local, and measures time elapsed since last
state change as far that single node is concerned.

It means that if the cluster has a known leader, we've been
available for at least max(timeElapsed[0], ..., timeElapsed[n]) seconds.
(max over all nodes)

Note: This does not necessarily mean the cluster was available
during that entire time, only that this particular node was started
this long ago.

Bug, observed after resilvering on PPS.

Two resilvering attempts in a row failed on PPS due to the low timeout.
(The third one succeeded)

Wrote a few days ago, but forgot to commit.

1M seems too low, we can go through that in less
than 2min at 14khz.

Should help detect the operator error occuring during PPS
migration: copying a live state machine (with disabled WAL..)

Otherwise, something went very wrong during replication, and
we'd better crash early.

Still a bit crude, needs more error checking.

Db reuse + rocksdb iterators seems like a bad combination.
Not entirely sure why.

Should improve replication performance - RocksDB supports efficient
iteration, which should be better than doing many point lookups.

Caught the following bug, accidentally introduced
yesterday I think:

    writeTracker.flushQueues("unavailable");

Should have been:

    writeTracker.flushQueues(Formatter::err("unavailable"));

After introducing the phantom type, the compiler caught the bug!
flushQueues was expecting a RedisEncodedResponse, and was getting
plain std::string instead.

This can naturally happen during a transition, so just print a warning.