Implement EF.Functions.JsonExists translation for SQL Server (#31136)

[kimjaejung96]

Note: I'm submitting this PR proactively because the previous attempts (#30010) appear to be inactive for a long time. I wanted to help move this forward.

• I've read the guidelines for contributing and seen the walkthrough
• I've posted a comment on an issue with a detailed description of how I am planning to contribute and got approval from a member of the team
• The code builds and tests pass locally (also verified by our automated build checks)
• Commit messages follow this format:

        Summary of the changes
        - Detail 1
        - Detail 2

        Fixes #bugnumber

• Tests for the changes have been added (for bug fixes / features)
• Code follows the same patterns and style as existing code in this repo

[kimjaejung96]

@dotnet-policy-service agree

[roji]

Thanks for submitting this @kimjaejung96. See below for some minor comments, but the bigger issue here is what this actually will be used for. As this PR is, we would notably not support complex/owned JSON documents (i.e. with ToJson()). I'm not sure whether that's an important scenario, since JSON columns mapped to .NET types to via ToJson() presumably have a very fixed schema, and dynamic-like JSON_EXISTS() wouldn't necessarily be very useful on them (though maybe if the schema evolves).

As this PR is, it seems this would only work for JSON columns that the user maps to .NET string; I'm not sure how many people actually do this.

So what exact usage scenario are you targeting here?

[kimjaejung96]

Thanks for the review @roji.

You're right that ToJson() is the way to go for fixed schemas. However, I'm targeting scenarios where the JSON structure is dynamic or weakly typed, making it difficult to map to a static CLR class.

For example:

1. E-commerce Attributes: Different products store different specs in the same column (e.g., Laptops have cpu, Shirts have size). Mapping all possible fields to a single class isn't feasible.
2. Raw Logs/Webhooks: Storing payloads from external services where the schema varies by event type.

In these cases, we simply store them as strings but still need to filter at the DB level using JsonExists.

I've also addressed your other feedback (primary constructors, removing reflection, and updating tests).

[roji]

@kimjaejung96 thanks for making the requested changes.

I reviewed this more deeply, and for this to be complete, it was lacking the following:

• Support for .NET types mapped to JSON as complex types (as opposed to just scalar string properties). This is slightly more complicated, and notably means a simple IMethodTranslator cannot be used, as these only work with scalar properties.
• SQL Server support only, although this should be relevant for all relational databases. This means both implementing SQLite support, and having test infrastructure for any relational database to use.
• Testing is lacking:
  • SQL Server-specific (as above)
  • Not testing the function against actual JSON data, to ensure the translation works correctly
  • Placed in the now-obsolete Northwind tests; testing should be in the newer Translations tests.

Since there's quite a bit of work here and it requires some familiarity, I've gone ahead and submitted #37477 which implements all of the above - take a look.

Your work here is much appreciated and helped trigger #37477 - thanks again!