storage_proxy: fix short reads in parallel range queries
storage_proxy: fix short reads in parallel range queries

Since a1cafed3701604c818609350fde504b81850b832 "storage_proxy: handle
range scans of sparsely populated tables" nonsingular range queries may
be performed in parallel on multiple shards. The consequence of this
that result may be added to the merger out of order. This requires more
complex logic for handling short reads.

As soon as mutation_result_merger gets a short read it starts to discard
all subsequently received results that are known to contain partitions
with larger keys.
Then when the final result is being prepared the merger may need to
combine and sorts results which ordering is not known. If at least one
of these results is a short one all partitions with larger keys are
removed.

Due to request being performed in parallel it is possible that even
though there was a short read the merger has got enough live data to
satisfy specified limits. If this has happened the short read flag is
not set on the final result.

avikivity/scylla,avikivity/scylla,avikivity/scylla,duarten/scylla,scylladb/scylla,raphaelsc/scylla,duarten/scylla,scylladb/scylla,raphaelsc/scylla,duarten/scylla,raphaelsc/scylla,scylladb/scylla,scylladb/scylla