Unified OpenSearch PPL Data Type

[penghuo]

Description

This PR introduces a language specification abstraction to support SQL and PPL query processing. The main changes include:

• A new interface, LangSpec, is added with a default SQL implementation and a custom PPLLangSpec that maps specific expression types (e.g., mapping BYTE to “tinyint”).
• Updates in index describe requests and query results ensure that the correct type names are used based on the active language specification (SQL or PPL).
• Updated tests verify the behavior of the language specification mappings and system index utilities.
• Updated OpenSearch PPL data type doc.

To Reviewer

• Ideally, Ideally, the query engine should use well-defined data types, with LangSpec serving as the protocol for translating these engine types to language-specific types. But, currently, the describe implementation relies on OpenSearchDataType (an extension of ExprCoreDataType). After the Calcite migration, all data types should be unified as CalciteDataType. then the specially handing in describe is not necessary.

Related Issues

#3339

Check List

• New functionality includes testing.
• New functionality has been documented.
• New functionality has javadoc added.
• New functionality has a user manual doc added.
• API changes companion pull request created.
• Commits are signed per the DCO using --signoff.
• 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.

[LantaoJin]

Since this is a breaking change, why don't we directly change the old type to the new type, instead of introducing LangSpec? Isn't this unnecessarily adding complexity?

[penghuo]

I agree. The core type was not upgraded because I intended for the data type changes to affect only PPL and not SQL. This PR focuses on unifying PPL data types, while SQL data types can be addressed in a separate issue, as changes there would impact JDBC, ODBC, and CLI.

Ideally, the query engine should use well-defined data types, with LangSpec serving as the protocol for translating these engine types to language-specific types. Once the Calcite implementation is complete, CalciteDataType will translate to ExprDataType, and LangSpec will translate from ExprDataType to the PPL response data type.