The first sequence number on the replicas is zero

Conflicting read request replies are not the leaders fault. So just
resend the request normally the first time.

A client could also reset it's certificate and retry the read
request for a newer sequence number.

This should lead to less mangled stack traces

The minimum is necessary for generating the keys not when
loading them

A replica directly replies with its current state to a weak
read requests. Therefore the client has to send the request
itself to all replicas.

This fixes hashed replies and weak read requests. In BFT
mode all replica should return a reply to the client. The only
question is whether a hashed reply is enough or not.

As the benchmark policy and the interval statistics start at
nearly exactly the same time this could cause the interval statistics
to report one interval too much or not.

This change slightly delays to policy start and suppresses printing
of the last incomplete interval. That way the first interval captures
slightly too little data (but that doesn't matter as it's normally cut
off anyways) and the last incomplete interval only captures data
for the fraction of a second.

This is useful for experiments where not all clients are active right from the start

This ensures that a local configuration test will trigger these checks.

This defers the creation of request paths until a
client is actually instantiated. Previously this initialization
happened when REFITConfig loaded the client class, which
slows down the configuration check.

When passing '--check' as first argument, then an experiment
will run a basic configuration check.

Previously only variant options were checked to actually override an
entry from refit-defaults. This now applies to all override options.

The implementation has moved to benchmark.py as JavaTestRun.
Wrapping the command with ssh is now a separate function and
gen_remote_java_cmd now also accepts an optional command prefix.