Fix SQL IT test queries, assertions, and data for engine-agnostic compatibility

[dai-chen]

Description

This PR fixed SQL integration tests so they behave consistently across query engines:

• Test queries: correct non-deterministic and non-standard-SQL queries, so the tests are stable and engine-independent.
• Test assertions: relax the shared schema matcher (column name and type) only on the analytics-engine route.
• Test data: remove unused array value from test data, because the bulk-load stripper only removes fields by unsupported type (but any field can hold an array value in OS, multi-value scalars can't be stripped generically per dataset).

Related Issues

Part of #5248

Check List

• New functionality includes testing.
• New functionality has been documented.
• New functionality has javadoc added.
• New functionality has a user manual doc added.
• New PPL command checklist all confirmed.
• API changes companion pull request created.
• Commits are signed per the DCO using --signoff or -s.
• Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🧪 No relevant tests

🔒 No security concerns identified

✅ No TODO sections

🔀 Multiple PR themes Sub-PR theme: Add ORDER BY clauses to fix non-deterministic test queries Relevant files: integ-test/src/test/java/org/opensearch/sql/legacy/OrdinalAliasRewriterIT.java integ-test/src/test/java/org/opensearch/sql/legacy/TypeInformationIT.java integ-test/src/test/java/org/opensearch/sql/sql/ConditionalIT.java Sub-PR theme: Relax schema matching for analytics-engine compatibility Relevant files: integ-test/src/test/java/org/opensearch/sql/util/MatcherUtils.java Sub-PR theme: Remove array values from test data and conditionally skip nested index load Relevant files: integ-test/src/test/resources/game_of_thrones_complex.json integ-test/src/test/java/org/opensearch/sql/legacy/PrettyFormatResponseIT.java

⚡ No major issues detected

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Add null-safety check for actualName The code doesn't handle null values for actualName before calling equals(), which could throw a NullPointerException. Add null-safety checks before the equality comparisons. integ-test/src/test/java/org/opensearch/sql/util/MatcherUtils.java [299-301] boolean nameMatches = - expectedName.equals(actualName) + (actualName != null && expectedName.equals(actualName)) || (!Strings.isNullOrEmpty(expectedAlias) && expectedAlias.equals(actualName)); Suggestion importance[1-10]: 8 __ Why: This is a valid concern as actualName could be null when queried from the JSONObject, and calling expectedName.equals(actualName) is safe but the second condition expectedAlias.equals(actualName) could fail if actualName is null. Adding null-safety improves robustness and prevents potential NullPointerException.	Medium
	Move static fields outside anonymous class The static fields inside an anonymous inner class can cause memory leaks and initialization issues. Move these constants outside the anonymous class to the class level or make them instance fields of the enclosing class. integ-test/src/test/java/org/opensearch/sql/util/MatcherUtils.java [280-281] +// Move to class level before the schema() method private static final Set<String> NUMERIC_TYPES = Set.of("integer", "long", "float", "double"); private static final Set<String> STRING_TYPES = Set.of("keyword", "text", "string"); +public static TypeSafeMatcher<JSONObject> schema( + String expectedName, String expectedAlias, String expectedType) { + return new TypeSafeMatcher<JSONObject>() { + // ... rest of implementation + }; +} + Suggestion importance[1-10]: 7 __ Why: While static fields in anonymous inner classes can cause issues in some contexts, the suggestion correctly identifies a potential problem. However, the impact is moderate as the code may work in many scenarios, and the issue is more about best practices than a critical bug.	Medium