Added scan support for indexed fieldTypes

[vinaykpud]

Description

End-to-end support for ip and binary field types on the analytics-engine read path, plus the planner-side adaptations needed to compare a VARCHAR literal against the underlying VARBINARY columns.

Related change in opensearch-project/sql#5443, which extended the SQL plugin to emit a BINARY(varchar) placeholder whenever a VARCHAR literal is compared to a VARBINARY column. This PR tells the analytics-engine planner and the DataFusion backend to consume that placeholder and execute against the parquet-backed columns end-to-end.

Scope

Three layers, in the order the data flows through them:

1. Schema / scan — ip and binary mappings now bind to a VARBINARY Calcite column. The Rust executor's substrait consumer normalizes the parquet BinaryView schema back to Binary before plan execution (schema_coerce::coerce_inferred_schema), since the DataFusion substrait consumer rejects the BinaryView shape that the parquet reader infers. DataFusion's DefaultPhysicalPlanner then inserts the runtime cast between the coerced schema and the underlying parquet BinaryView storage.

2. Predicates — BinaryFunctionAdapter rewrites the SQL plugin's BINARY(varchar) placeholder into a typed VARBINARY literal whose bytes match the on-disk encoding (InetAddressPoint-style 16-byte IPv6-mapped for ip, base64-decoded for binary). Wired into the filter / IN/BETWEEN/cidrmatchpaths viaSTANDARD_FILTER_OPS, OpenSearchTypeFactory.leastRestrictive`, and the existing CIDR expansion.

3. Project expressions — BINARY is now in STANDARD_PROJECT_OPS, so PPL eval if(col=lit, …), eval case(col=lit, …), and stats count(eval(col=lit)) no longer get rejected at the project gate. To keep the planner's per-slot type-validity assertion happy, the adapter now wraps its literal in makeAbstractCast(nullableVarbinary, …, false) — makeLiteral(ByteString, …) always reports BINARY(N) NOT NULL, which mismatches the column slot's nullable VARBINARY type and crashes the node inside LogicalProject.create when the literal lands in projection.

unsigned_long

OpenSearch's unsigned_long is a 64-bit unsigned integer. Substrait integers are signed-only and Calcite has no UNSIGNED BIGINT, so the type doesn't survive through the plan as-is.

1. Java side (OpenSearchSchemaBuilder.mapFieldType): map unsigned_long → BIGINT. The plan now treats the column as a signed 64-bit integer.
2. Rust side (schema_coerce::coerce_inferred_schema): rewrite the parquet-inferred UInt64 schema to Int64 before handing it to the substrait consumer. The parquet reader's SchemaAdapter reinterprets each batch from UInt64 → Int64 — this
   is a bit-pattern relabel (zero copy, no value transform).

half_float
OpenSearch's half_float is a 16-bit IEEE float that lands as Arrow Float16 in parquet. Calcite has no fp16 type, and Substrait emits fp32, so the column doesn't bind end-to-end

1. Java side (OpenSearchSchemaBuilder.mapFieldType): map half_float → REAL (Calcite's 32-bit float). The planner sees the same shape as a regular float column.
2. Rust side (schema_coerce::coerce_inferred_schema): rewrite the parquet-inferred Float16 schema to Float32 before handing it to the substrait consumer. The parquet reader's SchemaAdapter widens each batch with a real IEEE half→single conversion.

Related Issues

Resolves #[Issue number to be closed when this PR is merged]
opensearch-project/sql#5443

[github-actions]

❌ Gradle check result for 8beac7b: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❌ Gradle check result for 9303725: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❌ Gradle check result for b34d75d: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❕ Gradle check result for b622b44: UNSTABLE

Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.47%. Comparing base (a8c9190) to head (a1062c0).

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #21631      +/-   ##
============================================
- Coverage     73.53%   73.47%   -0.06%     
+ Complexity    74752    74745       -7     
============================================
  Files          5985     5985              
  Lines        339180   339180              
  Branches      48900    48900              
============================================
- Hits         249426   249223     -203     
- Misses        69851    70131     +280     
+ Partials      19903    19826      -77     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

✅ Gradle check result for 602db6c: SUCCESS

[github-actions]

❌ Gradle check result for a1062c0: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

✅ Gradle check result for a1062c0: SUCCESS