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.

This wouldn't have affected production, but it's causing
the build to occasionally fail.

This should make the cluster more stable (ie no spurious timeouts)
under heavy load.

As protection against misconfiguration - a lot of things depend
on the timeouts being identical across all nodes (most importantly leases)

This could be enhanced to also verify the consistency of the
key descriptors, but would become a lot more expensive.

The latest version of rocksdb disables RTTI by default,
so let's enable it back. Maybe it makes sense for QuarkDB
not to use RTTI either, but as long it does, the rocksdb
binaries have to as well.

The efficiency of the pattern matching depends on how many keys
start with the non-glob prefix of the pattern.

Examples

"abc*" will be very efficient, hitting just the keys
that match.

"*abc" will be inefficient, since we have to search through
the entire keyspace.

"ab?d" will have to iterate through all keys starting with
"ab".

I know these tests should probably be in qclient, but it's far easier
to test here, against a fully-functioning quarkdb cluster. Maybe fix
this later..

There's a small window between a leader getting elected
and its state machine catching up to the leadership marker,
during which it's unsafe to service reads, as there's the
possibility of giving out stale values.

Instead of giving an error to the client, stall the connection
until it's safe to reply.

The move constructor was buggy, since the thread would still retain
the original ThreadAssistant object it had during creation.

We still need a move constructor to store these in a vector, so
I should probably implement a correct one later.

When taking a checkpoint on node #0, it might be the only
one which hasn't caught up with the leader.. need to check first.

Just because a leader has emerged, doesn't mean the
leadership marker has been committed already! This made
us sometimes select the wrong entry to read with raft_fetch.

Still a couple of issues to be ironed out with tsan

Race uncovered by tsan, during resilvering.
Exceptionally unlikely to happen, but still..