ES|QL: Adding USER_AGENT command

[eyalkoren]

Closes #134886

Relies on the infrastructure that was introduced in #140712

Notes for reviewer

Column pruning via properties and extract_device_type at logical-plan creation

The properties and extract_device_type config options are resolved into the concrete set of output field names at the coordinator, inside LogicalPlanBuilder.visitUserAgentCommand(), before the logical plan node is even created. The UserAgent logical plan node receives only the already-filtered outputFieldNames — it has no awareness of properties at all. This means unrequested columns are never created, never serialized, and never allocated on data nodes.

Details object allocation per row is acceptable

Unlike URI_PARTS and REGISTERED_DOMAIN, where the bridge's evaluate() can write primitive values directly from the parsed result without intermediate allocations, the UserAgentParser.parseUserAgentInfo() API always returns a Details record (which itself contains VersionedName records for OS and device).

This does NOT represent a per-row allocation concern because results are served from a cache:

• Cache hit path: The UserAgentParser implementation maintains an internal LRU cache keyed by user-agent string. On cache hit, the previously allocated Details object is returned directly — no new allocation.
• Cache miss path: A full regex-based parse is required, which is itself a heavy operation involving multiple regex compilations and matches. The Details and VersionedName allocations are negligible compared to the regex parsing cost, and they must exist anyway because the result needs to be cached for future lookups.

[elasticsearchmachine]

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

[github-actions]

🔍 Preview links for changed docs

• docs/reference/query-languages/esql/commands/user-agent.md

[github-actions]

ℹ️ Important: Docs version tagging

👋 Thanks for updating the docs! Just a friendly reminder that our docs are now cumulative. This means all 9.x versions are documented on the same page and published off of the main branch, instead of creating separate pages for each minor version.

We use applies_to tags to mark version-specific features and changes.

Expand for a quick overview

When to use applies_to tags:

✅ At the page level to indicate which products/deployments the content applies to (mandatory)
✅ When features change state (e.g. preview, ga) in a specific version
✅ When availability differs across deployments and environments

What NOT to do:

❌ Don't remove or replace information that applies to an older version
❌ Don't add new information that applies to a specific version without an applies_to tag
❌ Don't forget that applies_to tags can be used at the page, section, and inline level

🤔 Need help?

• Check out the cumulative docs guidelines
• Reach out in the #docs Slack channel

[leemthompo]

Docs LGTM 👍

[ncordon]

Thanks for addressing my comments 🤗