ESQL: Clone ql for esql

[alex-spies]

Part of #106679

• Copy the ql project into a different project just for esql, call it esql-core.
• Make esql depend only on the latter.
• Fix EsqlNodeSubclassTests; I'm confused why this didn't bite us earlier.
• Update the warning regexes in some csv tests as the exceptions have other package names now.

Note to reviewers: Exclude the first commit when viewing the diff, as that contains only the actual copying of ql. The remaining commits are the actually meaningful ones. The build.gradle files probably require the most attention.

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[alex-spies]

Also kudos to @luigidellaquila - he made the first attempt in #106079, which however included renaming the namespaces and fixing up any imports.

[luigidellaquila]

Thanks Alex!
Just a couple of observations

This needs to be changed probably

https://github.com/elastic/elasticsearch/blob/main/x-pack/plugin/ml/qa/native-multi-node-tests/build.gradle#L18

It was not in my PR because it was added just one week after that.

This mixes EQL and ESQL, not sure if it can lead to classpath issues

https://github.com/elastic/elasticsearch/blob/main/x-pack/plugin/security/qa/consistency-checks/build.gradle#L16

[costin]

Since we don't aim to share the QL clone outside ESQL, why use it as a separate module instead of moving it directly into ESQL?

[alex-spies]

Since we don't aim to share the QL clone outside ESQL, why use it as a separate module instead of moving it directly into ESQL?

Moving that into the esql plugin directly would be more elegant. We could do that in a follow up if desired; I'd prefer not to do it in this PR, as that change is a bit less mechanical than just copying all the things, so more could go wrong.

[luigidellaquila]

Moving that into the esql plugin directly would be more elegant. We could do that in a follow up if desired; I'd prefer not to do it in this PR, as that change is a bit less mechanical than just copying all the things, so more could go wrong.

It could be less obvious than it seems: today Compute depends on QL, and we don't want it to depend on ESQL (but if I remember well, the dependencies were only on tests, so probably we can find an acceptable solution)

[alex-spies]

Thanks for the reviews @costin , @luigidellaquila , @breskeby and @rjernst !

I addressed your remarks, all should be good now. In particular, moved the esql-core classes into an own package, xpack.plugin.esql.core.

We can move the contents of esql-core into just esql later - hopefully placing the classes in esql.core will mean we won't have to update all the imports yet another time then.

[luigidellaquila]

Still a couple of fixes to make the CI happy (MlNativeIntegTestCase and EvalBenchmark), but apart from that, LGTM

Thanks Alex!!!

As a follow-up (this PR is big enough already), we'll have to double-check that the code generator still respects the code style (eg. the order of imports)