Add SPI for delegating row expression optimizer

[tdcmeehan]

Description

As part of RFC-0006, we need to support out of process expression evaluation. Add support for pluggable expression optimization and planner support to utilize the new SPI.

Motivation and Context

RFC-0006. See #24126 for larger changes that include the Presto sidecar as described in the RFC.

Impact

No impact by default as the old in-memory evaluation is the default.

Test Plan

Tests have been added.

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

== RELEASE NOTES ==

SPI Changes
* Add ``CoordinatorPlugin#getExpressionOptimizerFactories`` to customize expression evaluation in the Presto coordinator. :pr:`24144`

[pdabre12]

Thanks @tdcmeehan.
Just some initial comments

[github-actions]

Codenotify: Notifying subscribers in CODENOTIFY files for diff 3f4e4c3...4f56709.

No notifications.

[tdcmeehan]

Updates:

1. Removed DelegatingExpressionOptimizer and all related tests.
2. Added the ability to configure multiple expression optimizers and switch them based on a session property. Should be useful for fuzzer testing.

Thanks for the comments, please take another @ZacBlanco @rschlussel @aaneja @pdabre12

[ZacBlanco]

Two comments, otherwise lgtm

[rschlussel]

i don't like assuming that a session is a connectorSession. it breaks the abstractions. In this case all we care about is the session property. can we instead add a getSystemProperty() method to ConnectorSession?

[tdcmeehan]

While I agree this is not ideal, I'm of the opinion that it's worse to expose getSystemProperty to the SPI, because this allows all plugins to access system properties that were previously only known to the engine or runtime. While not ideal, I think this approach is a bit less worse because it's within presto-main, and we have examples of this being done for system connector and metadata tables provided to the JDBC driver. I do think that we should probably think of a better abstraction for how we provide session properties to plugins which are not connectors, and I've added a TODO and will open a Github issue to track it. Let me know if you think this is reasonable.

[rschlussel]

Fair criticism and suggestion to punt on resolving this. i do feel like the problem i'm talking about isn't about plugins that aren't connectors, it's easy enough to implement passing them ConnectorSessions. The thing that makes this require a ConnectorSession vs. a Session is that it gets called from connector optimizers. and we had similar issue with stats stuff a while back. The plugin separation break down when connectors call into stuff from presto-main.

[pdabre12]

Just two nits, otherwise LGTM.

[aditi-pandit]

+1 for presto-native-execution changes.