ES|QL kql function.

[afoucret]

This PR introduces support for the KQL query language as an ES|QL function.
Our main goal is to provides users a way forward to migrate from KQL to ES|QL by integrating KQL queries directly into ES|QL queries.

We recently added the support of KQL directly form the query DSL:

GET movies/_search
{
  "query": {
    "kql": {
      "query": "actors: \"Kurt Russel\" AND title: \"Big trouble\""
    }
  }
}

This PR expose this new capacity of the query DSL through a new KQL fulltext filtering function

POST _query
{
  "query": """
    FROM movies
    | WHERE kql("actors: \"Kurt Russel\" AND title: \"Big trouble\"")
  """
}

The KQL function is conceptually very similar to the QSTR function and come with the same limitations.

The new function is enabled only in snapshots builds (same for the KQL query in the query DSL)

[github-actions]

Documentation preview:

• ✨ Changed pages

[fang-xing-esql]

Thanks for putting these together @afoucret ! It looks pretty good to me, I added some comments.

Here are my understanding of the KQL function, and please correct me if I missed anything:

• In terms of the interface, the KQL function is very similar to QSTR so it makes sense to follow a similar approach as QSTR to support it in the ES|QL.
• However they are different in syntax according to this google doc, although their syntax look very similar to me, I won't be surprised that I might make mistakes on the syntax when using them. From users perspective, it will be helpful to have a page(or a link to existing ES docs) in the ES|QL doc to describe when to use KQL and when to use QSTR, and have examples to describe the usages. Especially they are now both available through ES|QL we may want to suggest the best practice to reduce confusions. Perhaps it is only me, but I'm not clear when I should use which function. This is not a needed for a snapshot function, but it will be helpful to get us prepared for a tech preview or GA.
• I suggest to add ES|QL-ui label to notify kibana about this new function, it is near the FF of 8.17, it will be nice to give them a heads up if this is targeting to 8.17.
• I suggest to add test-release label to run this through release tests, sometimes it does catch surprise for us.

[fang-xing-esql]

We could do a refactor here to reduce repetitive code, if Kql and QueryString have the same restrictions, they can be added in a collection and call checkCommandsBeforeExpression in a loop.

[afoucret]

Added a loop that remove the duplicated code.

[fang-xing-esql]

Shall we follow the alphabetical order here?

[afoucret]

Done. Thank you.

[fang-xing-esql]

The override to functionName can be skipped, as the function name is the same as class name.

[afoucret]

Removed the override.

[fang-xing-esql]

This annotation can be skipped, as the class name is the same as function name.

[afoucret]

Removed the annotation.

[elasticsearchmachine]

Pinging @elastic/kibana-esql (ES|QL-ui)

[afoucret]

@fang-xing-esql Thanks for the detailed review and feedback!

You're absolutely right that the KQL and QSTR functions are quite similar.
Both allow to leverage the _search infrastructure to execute another query language (respectively the Kibana Query Language and Lucene query string).

That said, for KQL, our intention is not to promote it as a standalone feature but rather to facilitate users migrating to ES|QL. This is why we’ve kept communication about it relatively low-key.
I will work on enriching the documentation by adding a link to the existing KQL page.

Few other points:

• I updated the code per your suggestions.
• I added the test-release label to ensure those tests are sucessful
• I updated the version label to target 8.18.0 instead of 8.17.0
• I added the ES|QL-ui label to keep the Kibana team informed of the progress

[fang-xing-esql]

Thank you @afoucret! LGTM. And thanks to @carlosdelest for reviewing as well.

[elasticsearchmachine]

💚 Backport successful

Status	Branch	Result
✅	8.x