Query: Fixes query plan via service interop to use custom serializer

[j82w]

Pull Request Template

Description

Customer can pass a customer serializer in which can apply and data transformation necessary. For example it could convert a int or double to a string.

Query has 3 different ways to get the query plan.

1. ServiceInterop.dll which requires Windows x64
2. Antlr parser
3. Gateway

The custom serializer is used in query for the following scenarios.

1. ServiceInterop.dll-> Using a random JsonConvert instead of the standard serialization contract
2. Antlr parser -> Does not take in parameters so serialization is not necessary. It just looks at query text.
3. Gateway -> Applies the correct serialization
4. Executing the query(sending it to gateway or a partition): Applies the correct serialization

Why didn't testing catch this?

There are existing tests which validate this scenario, but they are not calculating the correct expected count. The test assumed the query pipeline would only serialize the SqlQuerySpec once. The implementation serializes it for every page request to the backend and to generate the query plan.

Who is impacted?

Only customers that are running on Windows x64 and have custom serialization that filters on the partition key value only in the query. If the partition key is provided in the request options then it is handled correctly because request option overrides the query text.

Impact:

This could result in the query being sent to the wrong partitions' which would cause it query returning possibly less results than expected because it would be routed to the wrong partition.

Solution:

Based on the current models and contract the serialization logic should not be in the query code. The query pipeline should not know or care about how the parameters are serialized.

To keep this abstraction in place the serialization logic will be moved the CosmosQueryClientCore.cs like all of the other places that currently handle the custom serialization. This keeps all the serialization logic in the same file, and keeps it the same for all the different methods to get the query plan.

This will cause the serialized string to be passed down instead of the SqlQuerySpec. This is a better contract because the service interop only requires the serialized string. All the contracts now match what is actually needed for it to execute getting the query plan. This follows the same model as getting it from gateway or sending it to be executed.

Type of change

Please delete options that are not relevant.

• [] 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

To automatically close an issue: closes #3153

[neildsh]

Please add more description to explain why this change is required. A good example would be something like this: #3137

---

In reply to: 1105722954

[neildsh]

Please add baseline tests that illustrate how this change is used

[neildsh]

🕐

[ealsur]

LGTM, only minor comments

[kr-santosh]

@sboshra Hi Samer could you have a look at it and sign off on the PR.

[neildsh]