Add plan validator for timestamp with timezone check for prestissimo

[feilong-liu]

Description

Detail in discussion of #23191

Add a plan checker for Prestissimo, so that queries which have timestamp with timezone type will fail.

Motivation and Context

Fix facebookincubator/velox#10338

Impact

Only affect Prestissimo

Test Plan

existing unit tests and
end to end test with queries in the issue:

presto:sf1> select cast(x as timestamp with time zone), count(1) from unnest(array['2024-04-10 07:00 America/Los_Angeles', '2024-04-10 10:00 America/New_York']) as t(x) group by 1;
Query 20240712_205745_00033_5bggp failed: Timestamp with Timezone type is not supported in Prestissimo
java.lang.IllegalStateException: Timestamp with Timezone type is not supported in Prestissimo
	at com.google.common.base.Preconditions.checkState(Preconditions.java:507)
	at com.facebook.presto.sql.planner.sanity.CheckNoTimestampWithNoTimezoneType$Visitor.visitPlan(CheckNoTimestampWithNoTimezoneType.java:63)
	at com.facebook.presto.sql.planner.sanity.CheckNoTimestampWithNoTimezoneType$Visitor.visitPlan(CheckNoTimestampWithNoTimezoneType.java:50)
	at com.facebook.presto.spi.plan.PlanVisitor.visitOutput(PlanVisitor.java:25)
	at com.facebook.presto.spi.plan.OutputNode.accept(OutputNode.java:98)
	at com.facebook.presto.sql.planner.sanity.CheckNoTimestampWithNoTimezoneType.validate(CheckNoTimestampWithNoTimezoneType.java:47)
	at com.facebook.presto.sql.planner.sanity.PlanChecker.lambda$validateFinalPlan$0(PlanChecker.java:81)
	at com.google.common.collect.ImmutableList.forEach(ImmutableList.java:407)
	at com.facebook.presto.sql.planner.sanity.PlanChecker.validateFinalPlan(PlanChecker.java:81)
	at com.facebook.presto.sql.Optimizer.validateAndOptimizePlan(Optimizer.java:131)
	at com.facebook.presto.execution.SqlQueryExecution.lambda$createLogicalPlanAndOptimize$3(SqlQueryExecution.java:557)
	at com.facebook.presto.common.RuntimeStats.profileNanos(RuntimeStats.java:136)
	at com.facebook.presto.execution.SqlQueryExecution.createLogicalPlanAndOptimize(SqlQueryExecution.java:555)
	at com.facebook.presto.execution.SqlQueryExecution.start(SqlQueryExecution.java:463)
	at com.facebook.presto.$gen.Presto_null__testversion____20240712_205726_4.run(Unknown Source)
	at com.facebook.presto.execution.SqlQueryManager.createQuery(SqlQueryManager.java:319)
	at com.facebook.presto.dispatcher.LocalDispatchQuery.lambda$startExecution$8(LocalDispatchQuery.java:213)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)

Contributor checklist

• Please make sure your submission complies with our development, formatting, commit message, and attribution guidelines.
• PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced.
• Documented new properties (with its default value), SQL syntax, functions, or other functionality.
• If release notes are required, they follow the release notes guidelines.
• Adequate tests were added if applicable.
• CI passed.

Release Notes

Please follow release notes guidelines and fill in the release notes below.

== RELEASE NOTES ==

General Changes
* Add a plan checker so that queries having timestamp with timezone type will fail in prestissimo :pr:`23200`

[aditi-pandit]

@feilong-liu : Thanks for this code. MIght be great to put this behind a co-ordinator config so that we can enable/disable in our clusters easily as the underlying issue is getting fixed in Velox.

[feilong-liu]

@feilong-liu : Thanks for this code. MIght be great to put this behind a co-ordinator config so that we can enable/disable in our clusters easily as the underlying issue is getting fixed in Velox.

Added one more feature config for it

[amitkdutta]

Looks good from my end.
@aditi-pandit @tdcmeehan See if you have any comments.

[amitkdutta]

Nice! Thanks for validating the behavior in e2e tests.

[amitkdutta]

@gggrace14 @kgpai @kagamiori For testing the timestamp comparison features, we will need to turn this on in deployment configs.

[aditi-pandit]

+1. LGTM