[ES|QL] Add validation coverage for wildcards on commands

[dej611]

Summary

This PR extends the validation logic to cover also wildcase scenarios for various commands:

• wildcards are now supported by drop and keep:

• the special case of drop * is marked as error:

• a fuzzy search is performed over fields and variables for wildcard names, and errors are reported if no match is found:

• handled also the case of drop @timestamp with a warning:

Notes:

• by*tes *bytes and bytes* will all match bytes from my tests on ES, therefore the validation will make them pass as valid if there's a bytes field.

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

Pinging @elastic/kibana-visualizations (Team:Visualizations)

[drewdaemon]

All your examples work great! However, I get a validation error when dropping with the wildcard at the first, even though it successfully drops the field. Same thing happens if the wildcard is in the middle of the term.

Screen.Recording.2023-10-30.at.1.14.18.PM.mov

[dej611]

Good findings. I've never seen such usage in general. I'll try to add them as well.

[dej611]

@drewdaemon addressed the issues with b54e6f2

[drewdaemon]

Works great! I had one question about the necessity of the skipCommonValidation flag.

I'm approving but I added the docs label because I think it would be nice to get their feedback on the validation messages.

[drewdaemon]

Is there any reason we can't just use the presence of the validate method to decide (i.e. a clean override)?

[dej611]

Initially that was the design, but then I rolled back to this other decision.
There are several reasons for this change:

• shared validation code is quite a big surface and replicate it every time to just add a tiny little bit of extra ad-hoc validation doesn't make sense
• therefore I want a way to add only this extra validation bit on top of the common one
• ideally I would like to have a "positive" flag (something like commonValidation: true) but I've only few cases (one so far) where this extra bit is required and adding a "negative" ("skipCommonValidation") was the less intrusive one

Another design approach could be to rename validate as extraValidation to semantically avoid this flag + callback confusion.

[dej611]

I'm approving but I added the docs label because I think it would be nice to get their feedback on the validation messages.

I've planned a copy review of all messages once all the validation has been merged into the feature branch.
That is because some messages depends on ES current error message copy while others are specific to Kibana and I need to flag them for the copy team.

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: bc5f790

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
textBasedLanguages	149.4KB	149.4KB	+1.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
kbnUiSharedDeps-srcJs	2.3MB	2.3MB	+1.7KB

History

• 💛 Build #172191 was flaky 897478c
• 💔 Build #172165 failed d28d1f8
• 💚 Build #172133 succeeded 6e65c93
• 💔 Build #172121 failed a5c568a
• 💛 Build #171695 was flaky c2c3458
• 💔 Build #171504 failed deb076b

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream