Support 'EXTRACT' as a scalar function

[yashmayya]

• Fixes Support EXTRACT as scalar function #13462
• The extract transform function was originally added in Add support for EXTRACT syntax and converts it to appropriate Pinot expression #9184 but since there's no scalar version of it, it can't be used for literal evaluation or an intermediate stage in the multi-stage query engine (similar to Add some missing geospatial scalar functions to support use in intermediate stages with the v2 query engine #13457).
• It is critical to support the EXTRACT function since in the v2 engine, numerous functions are rewritten to a call to EXTRACT by Calcite.
• This patch does some minor refactoring so that there is no code duplication but we can still use extract as both a transform and scalar function.
• The existing tests from Add support for EXTRACT syntax and converts it to appropriate Pinot expression #9184 and [multistage] Support TIMESTAMP type and date ops functions #11350 verify this change's correctness and this patch adds some additional coverage for Add extract(quarter/dow/doy) support #11388.
• The change in PinotEvaluateLiteralRule is required to support the use of the new scalar function with literals in intermediate stages with the multi-stage query engine.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 80.00000% with 4 lines in your changes missing coverage. Please review.

Project coverage is 62.06%. Comparing base (59551e4) to head (bf1120c).
Report is 694 commits behind head on master.

Files	Patch %	Lines
...rg/apache/pinot/common/function/DateTimeUtils.java	86.66%	1 Missing and 1 partial ⚠️
...ot/calcite/rel/rules/PinotEvaluateLiteralRule.java	0.00%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #13463      +/-   ##
============================================
+ Coverage     61.75%   62.06%   +0.31%     
+ Complexity      207      198       -9     
============================================
  Files          2436     2559     +123     
  Lines        133233   141341    +8108     
  Branches      20636    21928    +1292     
============================================
+ Hits          82274    87727    +5453     
- Misses        44911    46950    +2039     
- Partials       6048     6664     +616     

Flag	Coverage Δ
custom-integration1	<0.01% <0.00%> (-0.01%)	⬇️
integration	<0.01% <0.00%> (-0.01%)	⬇️
integration1	<0.01% <0.00%> (-0.01%)	⬇️
integration2	0.00% <0.00%> (ø)
java-11	61.99% <80.00%> (+0.28%)	⬆️
java-21	61.94% <80.00%> (+0.32%)	⬆️
skip-bytebuffers-false	62.05% <80.00%> (+0.30%)	⬆️
skip-bytebuffers-true	61.87% <80.00%> (+34.14%)	⬆️
temurin	62.06% <80.00%> (+0.31%)	⬆️
unittests	62.06% <80.00%> (+0.31%)	⬆️
unittests1	46.67% <80.00%> (-0.22%)	⬇️
unittests2	27.58% <0.00%> (-0.15%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[yashmayya]

CalciteSqlCompilerTest.testExtract is failing with:

Caught exception while invoking method: public static int org.apache.pinot.common.function.scalar.DateTimeFunctions.extract(java.lang.String,long) with arguments: [YEAR, 2017-06-15]

However, the test itself seems a little odd because even before the changes from this PR, while the test passes (i.e., the query compiles to a v1 Pinot query), trying to run an actual query like SELECT EXTRACT(YEAR FROM '2017-06-15') FROM table; results in a similar type related error:

Error Code: 200

QueryExecutionError:
java.lang.IllegalArgumentException: Invalid long value: 2017-06-15
	at org.apache.pinot.common.request.context.LiteralContext.getLongValue(LiteralContext.java:258)
	at org.apache.pinot.core.operator.transform.function.LiteralTransformFunction.getLongLiteral(LiteralTransformFunction.java:65)
	at org.apache.pinot.core.operator.transform.function.LiteralTransformFunction.transformToLongValuesSV(LiteralTransformFunction.java:141)
	at org.apache.pinot.core.operator.transform.function.ExtractTransformFunction.transformToIntValuesSV(ExtractTransformFunction.java:61)

@Jackie-Jiang can the test be updated to use timestamps in the form of milliseconds since epoch or is there some other missing context here?

[yashmayya]

The only reason the test wasn't failing earlier was that since there was no scalar function for EXTRACT, the compile time function invoker query rewriter skips evaluation here when the query rewrite rules are being invoked here during the Pinot query compilation. So, the test didn't make much sense since the EXTRACT function never supported timestamp strings (that aren't milliseconds since epoch) in the first place. I've updated the test and also rebased this on top of changes from #13483.