Query: Fixes GetItemQueryIterator to honor the supplied (optional) FeedRange

[adityasa]

Query: Fixes GetItemQueryIterator to honor the supplied (optional) FeedRange

Description

This change supports query execution using serialized FeedRange supplied to GetItemQueryIterator. It limits the query execution to specified feed ranges by using start epk and end epk values.
This is done by adjusting PartitionKeyRange of each partition to be >= min and <= max of the supplied range after target partitions have been identified. While this is not logically accurate, since PartitionKeyRange represents the ranges of a physical partition, and technically there may not be a physical partition with exact ranges after they have been adjusted using user supplied range and (the adjusted range is a subset of a physical partition range), this is rather only a semantic issue. Also, once the target range (adjusted or not) is obtained, they are anyways converted to FeedRangeEpk which represents a slice of a partition.
This logic of "clipping" a partition is similar to what we do in case of Hierarchical partition and we repurpose the existing class for locality of knowledge.

Note: QueryRequestOptions has a FeedRange property. However this is NOT the property that gets used when the GetItemQueryIterator API with FeedRange is called. In fact, QueryRequestOptions.FeedRange is an internal property.

I also explored the option of populating the start-epk and end-epk headers in QueryRequestOptions::PopulateRequestOptions as an alternative to "clipping" the PartitionKeyRange from target ranges.
This has following challenges:

1. Generally RequestInvokerHandler is in charge of setting epk and partition key related fields. It does so for all operations (including query). Breaking this pattern in a subset of cases is difficult from maintainability perspective.
2. QueryRequestOptions is user input and should be treated as immutable. Modifying it to store FeedRange breaks this principal

Caveats:
Please note due to the difference in types being utilized internally and externally (deserialized type), we are only able to support feedranges with min being inclusive and max being exclusive - [min, max)
Moreover there is no validation against "unsupported values" and they are automatically interpreted as [min, max).

Type of change

• Bug fix (non-breaking change which fixes an issue)
• [] New feature (non-breaking change which adds functionality)
• [] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [] This change requires a documentation update

Closing issues

Closes #5451

[adityasa]

we are only able to support feedranges with min being inclusive and max being exclusive - [min, max)
Moreover there is no validation against "unsupported values" and they are automatically interpreted as [min, max).

• this should be listed as a known issue.