Range read concurrency factor didn't consider range merger

During range read, coordinator computes concurrency factor which is the number of vnode ranges to contact in parallel for the next batch.

But in RangeCommandIterator, vnode ranges are merged by RangeMerger if vnode ranges share enough replicas to satisfy consistency level. eg. vnode range [a,b) has replica n1,n2,n3 and vnode range [b,c) has replica n2,n3,n4, so they can be merged as range [a,c) with replica n2, n3 for Quorum.

Currently it counts number of merged ranges towards concurrency factor. Coordinator may fetch more ranges than needed.

Another issue is that when executing range read on table with very small amount of data, concurrency factor can be bumped to size of total vnode ranges, eg. 10k, depending on the num of vnodes and cluster size. As a result, coordinator will send large number of concurrent range requests, potentially slowing down the cluster.. We should cap the max concurrency factor..