[Test] Simplify SQL Server feature checks to use only compatibility level

[ErikEJ]

Remove SQL Server version and Azure checks from feature detection in TestEnvironment. Feature support is now determined solely by compatibility level, streamlining logic and reducing complexity. Update SetCompatibilityLevelFromEnvironment to use GetCompatibilityLevel() directly.

Also, FYI: Vector is supported on LocalDB provided the latest CU is installed: see https://erikej.github.io/sqlserver/localdb/2026/03/13/localdb-sqlserver-2025.html

Notice that the compatibility level is read from the master database, and tests usually run against a user database.

• 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

[Copilot]

Pull request overview

This PR simplifies SQL Server feature detection in the SQL Server functional tests by removing product-version and Azure-specific checks for several feature flags and relying solely on database compatibility level. It also updates test options configuration to set EF’s compatibility level directly from the detected compatibility level.

Changes:

• Updated multiple TestEnvironment feature flags (temporal cascade delete, UTF-8, JSON path expressions, Functions 2017/2019/2022, JSON type) to check only GetCompatibilityLevel().
• Changed SetCompatibilityLevelFromEnvironment to use GetCompatibilityLevel() rather than SqlServerMajorVersion * 10.

[roji]

This makes sense to me; though I'd personally remove all the feature-specific flags (_supportsUtf8, _supportsJsonPathExpressions...) and replace all that stuff with a simple attribute where the tests specifies the compatibility level it wants. I don't really see what all these separate flags and attributes bring us.

@AndriySvyryd what's your view?

[AndriySvyryd]

There are some features that are not tied strictly to the compatibility level or have a different mapping to the level on Azure SQL.
An even more minor point is to use this as documentation for the reason why a specific compatibility level is required.
But I don't have a strong preference for keeping the flags

[roji]

There are some features that are not tied strictly to the compatibility level or have a different mapping to the level on Azure SQL.

That's true, full-text search is a separately-installed feature.

How about we remove the special handling for features which are simply covered by he compatibility level (I think that's most), and keep the others, at least for now?

[ErikEJ]

@roji @AndriySvyryd many of the conditions rely on not only the compat level, but these can be removed and just be replaced with a compat level check:

public static bool IsTemporalTablesCascadeDeleteSupported
public static bool IsUtf8Supported
public static bool SupportsJsonPathExpressions
public static bool IsFunctions2017Supported
public static bool IsFunctions2019Supported
public static bool IsFunctions2022Supported
public static bool IsJsonTypeSupported

Requested additional changes