Use appropriate rerank code path for validation call

[DonalEvans]

This commit introduces a RerankServiceIntegrationValidator class to be used when validating rerank endpoints that support the new code path, which calls rerankInfer() instead of infer(). Services that do not support the new code path continue to use SimpleServiceIntegrationValidator, which calls infer().

This commit also renames CustomServiceIntegrationValidator to CustomServiceRerankIntegrationValidator and calls rerankInfer() there, since the Custom service has been converted to the new code path.

Other changes:

• Extract the common logic to wrap the listener for a validation call to
  the ServiceIntegrationValidator interface

[elasticsearchmachine]

Pinging @elastic/search-inference-team (Team:Search - Inference)

[elasticsearchmachine]

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

[github-actions]

🔍 Preview links for changed docs

⏳ Building and deploying preview... View progress

This comment will be updated with preview links when the build is complete.

[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

[jonathan-buttner]

@elasticmachine test this please

[jonathan-buttner]

I verified the fix end to end using cloud-deploy and qaf. Thanks for the fix.

PUT _inference/rerank/test
{
    "service": "elastic",
    "service_settings": {
        "model_id": "jina-reranker-v2-base-multilingual"
    }
}

POST _inference/test
{
    "input": [
        "Carson City is the capital city of the American state of Nevada.",
        "The Commonwealth of the Northern Mariana Islands is a group of islands in the Pacific Ocean. Its capital is Saipan.",
        "Washington, D.C. (also known as simply Washington or D.C., and officially as the District of Columbia) is the capital of the United States. It is a federal district.",
        "Capitalization or capitalisation in English grammar is the use of a capital letter at the start of a word. English usage varies from capitalization in other languages."
    ],
    "query": "What is the capital of the United States?"
}

[jonathan-buttner]

@elasticmachine run Elasticsearch Serverless Checks

[elasticsearchmachine]

This PR has been labeled blocker, which will prevent Elasticsearch Serverless from being promoted until this PR is merged and its merge commit is included in the promoted build.

To resolve this blocker:

• Merge this PR
• The promotion check will pass automatically once the merge commit is included in the build being promoted

Optional — narrow the scope with Introduced in:

If the bug was introduced in a specific commit, add the following line to this PR's description:

Introduced in: <commit-sha-or-pull-request-url>

This tells the promotion check that builds predating this commit are unaffected and should not be blocked. For the commit SHA, both the short (7-character) and full (40-character) SHA are accepted.

For more information, see the Promotion Blocker documentation.