Coral-Trino: Migrate function operator transformers defined in CalciteTrinoUDFMap from RelNode layer to SqlNode layer

[yiqiangin]

The code changes include:

• Adding a class of OperatorBasedSqlCallTransformer which extends SqlCallTransformer and its condition is implemented based on the input operator name and the number of the operands
• Adding the class of LinkedInOperatorBasedSqlCallTransformer which is a subclass of OperatorBasedSqlCallTransformer and transforms a Coral operator into a Trino operator on SqlNode layer for the LinkedIn specific functions
• Adding a class of MapStructAccessOperatorTransformer which is an ad-hoc SqlCallTransformer which converts the map struct access operator "[]" defined from Calcite in a SqlIdentifier into a UDF operator of "element_at", e.g. from "col"["field"] to element_at("col", "field")
• Removing the code of transforming standard UDF operators defined in CalciteTrinoUDFMap in the class of Calcite2TrinoUDFConverter on RelNode layer
• Adding a class named CoralToTrinoSqlCallConverter which extends the class of SqlShuttle and initialize a class of SqlCallTransformers which containing a list of SqlCallTransformer to traverse the hierarchy of a SqlCall and converts the functions from Coral operator to Trino operator if it is required
• Calling CoralToTrinoSqlCallConverter to convert function operators on SqlNode layer in the class of RelToTrinoConverter
• Adding the class of ToDateOperatorTransformer as an Ad Hoc SqlCallTransformer as it needs to check the configuration parameter of AVOID_TRANSFORM_TO_DATE_UDF in its condition function
• Some small changes on the names of date related UDF functions which should be recognized on SqlNode layer

To be noted that the migration from UDF operator transformers based on JSON infra to those implemented in Java code will be done in another several separated PRs

[wmoustafa]

The class CalciteTrinoUDFOperatorTransformers seems complicated and I think it could use further simplification.

[wmoustafa]

I think this PR migrates operators beyond ones leveraging JSON infra right? Might consider updating the title/description if necessary.

[ljfgem]

Thanks @yiqiangin for this PR!

[wmoustafa]

Ideally, everything is just a SqlCallTransformer or an extension of it.
Common transformation patterns (e.g., same condition based on signature) could leverage one extension together.
Similarly for Dali UDFs, either join forces with an existing extension, or create their own extension based on the condition/transformation pattern.

[ljfgem]

Thanks @yiqiangin, please run regression test for Trino again after addressing the comments.

[ljfgem]

@yiqiangin: please resolve the conflicts.
@wmoustafa: do you want to take another look?

[wmoustafa]

What is the objective of Calcite2TrinoUDFConverter class? I feel it can be refactored to a transformer or a set of transformers.

[yiqiangin]

What is the objective of Calcite2TrinoUDFConverter class? I feel it can be refactored to a transformer or a set of transformers.

@wmoustafa From my understanding, Calcite2TrinoUDFConverter converts UDFs by both standard transformers and ad-hoc transformers (as described in @ljfgem design document ) on RelNode layer. All the standard transformers are defined in CalciteTrinoUDFMap. The scope of this story is to migrate these standard transformers from RelNode layer into SqlNode layer. The remaining ad-hoc converters in Calcite2TrinoUDFConverter are planned to be refactored in another work according to @ljfgem 's design. @ljfgem pls correct me if I am wrong.

[ljfgem]

Thanks @yiqiangin, please rerun the regression test after addressing all the comments.

[aastha25]

Thanks @yiqiangin for working on this PR!

[wmoustafa]

I have simplified the APIs. You can take a look here.

[ljfgem]

I don't have other major concerns. Let's merge if no major concerns from @wmoustafa.

[wmoustafa]

LGTM. Great work @yiqiangin! Thanks!