Add match support for semantic_text fields

[kderusso]

Followup on #112166

Implements match query support for semantic_text fields.

The following design changes were made from the original POC:

• Replaces the idea of the query builder service by a query rewrite interceptor that can be defined by plugins.
• match queries on combined text and semantic_text field will no longer error but will return results.

Example script of how to use it:

PUT _inference/sparse_embedding/my-elser-endpoint
{
  "service": "elser",
  "service_settings": {
    "num_allocations": 1,
    "num_threads": 1
  },
  "task_settings": {}
}

PUT my-index-1
{
    "mappings": {
        "properties": {
            "inference_field": {
                "type": "semantic_text",
                "inference_id": "my-elser-endpoint"
            },
            "text_field": {
                "type": "text"
            }
        }
    }
}

PUT my-index-2
{
    "mappings": {
        "properties": {
            "inference_field": {
                "type": "text"
            },
            "text_field": {
                "type": "text"
            }
        }
    }
}

POST my-index-1/_doc/1
{
  "inference_field": "a test value",
  "text_field": "a test value"
}

POST my-index-2/_doc/1
{
  "inference_field": "a test value",
  "text_field": "a test value"
}

GET my-index-1/_search
{
  "query": {
    "match": {
      "inference_field": "test"
    }
  }
}

GET my-index-1/_search
{
  "query": {
    "match": {
      "text_field": "test"
    }
  }
}

GET my-index-*/_search
{
  "query": {
    "match": {
      "inference_field": "test"
    }
  }
}

[Mikep86]

Great work! I left a few comments, mostly nits.

[Mikep86]

Dumb question: how does this interceptor know to only intercept match queries?

Update: After reviewing the code further, I understand how this interceptor only intercepts match queries. However, this behavior is based on an implementation detail that I think could easily trip us up later. We use QueryRewriteInterceptor#multi to create an interceptor lookup map. However, QueryRewriteContext will accept any QueryRewriteInterceptor, including one not created by QueryRewriteInterceptor#multi. Could we update the classes and method signatures to to enforce that that the rewrite context should take a map of interceptors?

We don't need to do it in this PR, but I think it's something good for a follow-up.

[kderusso]

I get it. I think that we certainly could do that, and I'd argue that if we decide to go down that route, maybe we get rid of the CompositeQueryRewriteInterceptor concept at all in favor of a service class that will do the right thing. I'll think about it, but I'd like to do that in a followup if we decide that's the best direction to go in, as it won't impact transport serialization or other features.

[Mikep86]

Match query support with multiple inference endpoints is already broken (due to the index filter clause running as a post-filter), so we can consolidate to a single clause now.

[carlosdelest]

Thanks for implementing the rewriting test!

[carlosdelest]

Nice test! 💯

Should we test that an additional rewrite on an intercepted query returns the same query, so we know the rewrite cycle ends?

[elasticsearchmachine]

💔 Backport failed

Status	Branch	Result
❌	8.x	Commit could not be cherrypicked due to conflicts

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 117839

[kderusso]

💚 All backports created successfully

Status	Branch	Result
✅	8.x

Questions ?

Please refer to the Backport tool documentation