ESQL: Introduce language versioning

[costin]

Description

As the ESQL grammar evolves, we need to establish some guidelines around the grammar and what are the expectations for clients using an old version or a a new version against a cluster that hasn't been fully upgraded.

Break-down of tasks

• Enable and validate version parameter for _query endpoint ESQL: Introduce language versioning to REST API #106824
• Update docs ESQL: Add version to docs #107225 ESQL: More explanation for version #107363
• Update REST spec not necessary since we only change the body of the REST request, which is not covered by the REST spec.
• Update elasticsearch-specification Add esql version elasticsearch-specification#2512
• Update integration tests and make version a required parameter after some grace period. ESQL: Default ESQL version on old clients #107438 ESQL: Send language version in spec tests #107268 ESQL: Make esql version required in REST requests #107433
• Update rally benchmarks Send version with esql rally#1841 (comment)

[costin]

Another aspect of versioning is dealing with different planning across nodes:

1. a new node is upgraded and creates a different plan, that expects different local inputs
2. some of the local nodes are not upgraded and for the same plan, create an old output
3. the plan execution fails since the coordinator receives a different layout than the one expected from the old nodes.

To avoid this the coordinator would have to:

• either use the new rule only if all nodes are upgraded
• translate the old payload into a new one (assuming that is possible)

[elasticsearchmachine]

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