ES|QL Views

[craigtaverner]

Initial support for ES|QL Views. It is based on the underlying sub-query support added in ..., and builds on the Views REST API work done in #137818.

Checklist:

• Core prototype
  • Extract key parts of Nik's original prototype
  • Write testing infrastructure to test views within csv-spec tests (single and multi-node tests)
  • Expand REST API to cover get, list, create/update, delete views
  • Add size and count limitations to stored view definitions
  • Write testing infrastructure to test views in CsvTest (csv-spec unit testing)
  • Expand scope to nested views
  • Expand scope to multiple views and views+indexes
• Split into multiple PRs for easy review
  • Multi-relation index resolution (gives CCS/CPS support)
    • Multi-relation support, a pre-requisite for views and sub-queries #136780
  • More resilient EsqlSpecTestCase
    • Re-enable some performance updates to ES|QL spec tests after resilience improvement to EsqlSpecTestCase #136781
  • View CRUD with REST
    • ESQL: Views REST API #137818
  • Rebase prototype on the above to get cleaner, simple feature PR
• Enhancements
  • Prototype CCS and CPS
  • Enforce view/index name uniqueness (done in separate PR)
  • Add serialization tests to test source deserialization in re-written plans
  • Ensure views are gated behind SNAPSHOT and/or feature flag
  • Increate test coverage at least to the same extent as sub-queries
  • Control and/or restrict nesting/branching depth/width

[elasticsearchmachine]

Hi @craigtaverner, I've created a changelog YAML for you.

[julian-elastic]

This is not a good paradigm. It caused a 400 file change. How about we provide a createWarnings that takes source in? Then the next time you need to pass something from the source it is a one file change and not 400 file change?

[craigtaverner]

Done

[julian-elastic]

Overall, still looks good with the latest changes. However, I would recommend fixing tech debt where passing something from source to warnings requires 400+ files change.

[idegtiarenko]

NIT:
Instead of

 this.something = SETTING.get(settings);
clusterService.getClusterSettings().addSettingsUpdateConsumer(SETTING, (i) -> this.something = i);

please use

clusterService.getClusterSettings().initializeAndWatch(SETTING, v -> this.something = v);

that takes care about both initialization and keeping the value updated.

[craigtaverner]

OK. I did this and simplified my use of settings in general.

[elasticsearchmachine]

@craigtaverner according to this PR's labels, I need to update the changelog YAML, but I can't because the PR is closed. Please either update the changelog yourself on the appropriate branch, or adjust the labels. Specifically:

• The PR is not labelled release highlight but the changelog has a highlight section