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

Deserializing an entry when reading from the journal just
to serialize immediatelly when sending to the followers
is a bit pointless..

An check had been inserted into the wrong dispatcher,
making quarkdb erroneously reject certain commands.
(bulkload finalize, resilvering, etc)

Not caught by the tests beucase only the Shard class
is tested, not QuarkDBNode. :/ Should change this..

Off by default, of course. :) Configurable per-connection,
simply send "activate-stale-reads".

Works both with state machines and journals.

The goal is to be able to iterate over them in the planned
RecoveryEditor, to quickly see the most important values
for a state machine or journal.

*sigh*

Runs with tsan are slower, which has uncovered a lot
of mild races / flaky assertions in the tests. Not the
main code, though, happily.

Also remove "failover" from testcase names, it makes
it harder to grep for "fail" in a log to check if
there are failures. :P

It appears that ThreadSanitizer does not release memory to the OS,
or re-use the memory after a delete. This makes running the stress
tests difficult, as we run out of memory.

Let's try using a feature from gtest meant for distributed test
execution, which is to shard the tests over different runs. This
way, we will reclaim memory after each "shard" finishes running,
and use far less memory in total.

It could be that the leader has not yet been in contact
with all nodes, so removing any would result in loss
of quorum, triggering the loss-of-quorum protection,
and preventing the removal of the node.

This only happens on the newest Ubuntu 17.10 and Fedora 26, but
not CC7. No idea why.

Fixes EOS-2072, thanks to Herve Rousseau for the bug report

It appears that if rocksdb is compiled using tsan as well,
there are no more false positive data races - whooo. We
don't need the suppression file anymore. (which could potentially
mask real races)

cpack seemed like a good idea at the time, but causes the
following odd workflow:

cmake -> cpack -> archive -> rpm -> cmake

And moreover, doing anything slightly complicated in the
release tarball generation requires using crazy cmake syntax.
Bash seems far better for this.