Query: Fixes split proofing logic for queries with logical partition key

[bchong95]

Query: Fixes split proofing logic for queries with logical partition key

Description

Suppose the partition spans epk range A to E
And the user send a query with partition key that hashes to C

When we query the results the continuation token will look something like:

{
              "token": "blah",
              "range": {
                             "min": "A",
                             "max": "E"
              }
}

Now suppose there is a split that creates two partitions A to B and B to E

Now C will map to the partition that goes from B to E

When we run the following code:

https://github.com/Azure/azure-cosmos-dotnet-v3/blob/master/Microsoft.Azure.Cosmos/src/Query/Core/Pipeline/CrossPartition/PartitionMapper.cs#L68

We are going to hit an exception, since the code looks for a partition to resume from which in this case should be B to E, but we have the value A to E and we are checking to see if a partition matches the start of range (in this case A).

This leads to an exception.

This code path doesn’t happen in the case of non partition key queries, since the call to get target partition key ranges gives the full set of ranges and we always finish reading from the left most partition before moving on to the right most partition.

This fix detects if we are in a single partition scenario and resumes from that partition. The longer term solution is to wire FeedRangeState throughout the query stack (similar to what we have for ChangeFeed: #1978).

[ghost]

Closing due to in-activity, pease feel free to re-open.