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 0720f17...8c8d1f4.

No notifications.

[ZacBlanco]

At a high-level, the changes make sense. I had a few questions about the configuration and how we might be able to simplify it to be more straightforward for users

[ZacBlanco]

I feel like having an additional method to configure/load the expression optimizer is a bit of an anti-pattern. It creates the potential for bugs if someone is trying to properly create the expression manager by requiring this additional method to be called. I haven't dug much deeper, but is there a reason we can't perform the loading of the factory in the constructor of the expressionManager?

[tdcmeehan]

I believe the reason for this convention is these loading methods might entail something expensive, or that could fail, and it's helpful to do such things outside of Guice's bootstrapping process. Such failures are often very verbose because Guice returns the error in the context of where it failed during the bootstrapping process, and I think it's cleaner to do it outside of the Guice dependency graph so that the failure is clear and isolated.

[ZacBlanco]

Would it be possible to load it in a more lazy manner? Such as using guava's Suppliers.memoize instead?

Otherwise, if we don't want to defer loading configuration like that, then I think we should do some runtime assertion when ExpressionOptimizerManager.getExpressionOptimizer is called to verify that loadExpressionOptimizerFactory method has been called first.

[ZacBlanco]

not a big fan of having the duplicated code in these methods. Consider refactoring to a private method?

[tdcmeehan]

It's difficult as it stands because these two methods return different types. I raised #24287 which would make it easier to share code between the two methods.

[pdabre12]

Some comments,