[ESQL][Inference] Introduce usage limits for COMPLETION and RERANK

[afoucret]

Added implicits configurable Limit for COMPLETION and RERANK

• Execution limits
  • The maximum number of rows processed by COMPLETION and RERANK must be bounded by default.
  • When the input dataset exceeds this limit, it should be truncated before the command executes.
  • Administrators must be able to override or disable these limits through cluster settings:

Setting	Description	Default
esql.command.completion.enabled	Enable or disable the COMPLETION command	true
esql.command.completion.limit	Maximum number of rows to be processed by COMPLETION	100
esql.command.rerank.enabled	Enable or disable the RERANK command	true
esql.command.rerank.limit	Maximum number of rows to be processed by RERANK	1000

Updated documentation

• Documentation.
  • < 9.3
    • COMPLETION and RERANK documentation must explicitly warn about risks.
    • Documentation must strongly recommend adding a LIMIT before COMPLETION and RERANK.
  • >= 9.3.0 Added a note about the implicit limit in RERANK and COMPLETION

Others:

• Added to integration tests for COMPLETION and RERANK so we can have tests scenarios using settings

Closes: #136861

[elasticsearchmachine]

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

[elasticsearchmachine]

Pinging @elastic/es-search-relevance (Team:Search Relevance)

[elasticsearchmachine]

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

[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

[ioanatia]

we don't need to introduce a new transport version, in fact we don't need this method at all.
now that RERANK and COMPLETION have an implicit limit - they will always be executed on the coordinator, meaning we never need to send them to the data nodes.
so we can further simplify this, remove the NamedWritable and just throw an exception if we need to serialize them (which would be a bug and a code path that should never be reached):

elasticsearch/x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/plan/logical/Row.java

Lines 36 to 44 in 8f72b23

	@Override
	public void writeTo(StreamOutput out) {
	throw new UnsupportedOperationException("not serialized");
	}
	@Override
	public String getWriteableName() {
	throw new UnsupportedOperationException("not serialized");
	}

ChangePoint, Fuse, Fork etc are also not serialized.

[afoucret]

Completely removed the serialization logic for Rerank and Completion logical and physical plans.

[ioanatia]

the index we create always has 6 documents - so we are not really testing the limit enforcement.
let's change the createAndPopulateTestIndex so that we create an index with more than 100 documents when we test COMPLETION and more than 1000 when we test RERANK.
and here we should check that we get exactly 100 documents back.

[afoucret]

Test have been updated.

[ioanatia]

let's check we get exactly customLimit docs back (take a look at the other comment that suggests changing createAndPopulateTestIndex.

[afoucret]

Tests have been updated.

[leemthompo]

Docs preview LGTM, nice!

[ioanatia]

I wonder if we should consider embedding inferenceSettings in SettingsValidationContext?
I know that SettingsValidationContext serves a different purpose, so maybe we can just have a ValidationContext that is initialized in EsqlSession and can receive whatever context is necessary for validation during parsing?
Happy to do this as a separate follow up and not in this PR, since it would increase the scope.