### Description

When using a ML model with that outputs sparse vectors (like ELSER), it's possible that some times the inference pipeline fails when indexing new documents and new ingested documents are not enriched with the `sparse_vector` fields.

One approach in this case is to run an update by query and issue a reindexing with the ml pipeline of the documents in place in the same index.
In this case, we would want to only update the documents that do not have `sparse_vector` fields, for example:

```
POST search-books/_update_by_query?pipeline=ml-inference-books
{
  "query": {
    "bool": {
      "must_not": {
        "exists": {
          "field": "ml.inference.description_expanded.predicted_value"
        }
      }
    }
  }
}
```
In theory this a much simpler approach then duplicating all the data to reindex in another index or to reissue bulk indexing requests from scratch. It only requires a single Elasticsearch API request.

the problem is that `sparse_vector` fields do not support `exists` queries.

```
{
  "error": {
    "root_cause": [
      {
        "type": "query_shard_exception",
        "reason": "failed to create query: [sparse_vector] fields do not support [exists] queries",
        "index_uuid": "WkxxefxdTuCiNeLy4b33jw",
        "index": "search-books"
      }
    ],
    "type": "search_phase_execution_exception",
    "reason": "all shards failed",
    "phase": "query",
    "grouped": true,
    "failed_shards": [
      {
        "shard": 0,
        "index": "search-books",
        "node": "l5lxDFkeSwOyiwOEkQtWZA",
        "reason": {
          "type": "query_shard_exception",
          "reason": "failed to create query: [sparse_vector] fields do not support [exists] queries",
          "index_uuid": "WkxxefxdTuCiNeLy4b33jw",
          "index": "search-books",
          "caused_by": {
            "type": "illegal_argument_exception",
            "reason": "[sparse_vector] fields do not support [exists] queries"
          }
        }
      }
    ]
  },
  "status": 400
}
```

This also makes it difficult to get an accurate count of how many fields are missing the `sparse_vector` fields and users have to rely on other fields/mechanisms to do a reindexing in place with update by query.

NOTE: This will only be for the top level sparse_vector field. NOT for any of its sparse dimensions.

server/src/main/java/org/elasticsearch/index/IndexVersion.java
import java.util.NavigableMap;
import java.util.ServiceLoader;
import java.util.Set;
import java.util.TreeMap;
/**
 * The index version.
 * <p>
 * Prior to 8.8.0, the node {@link Version} was used everywhere. This class separates the index format version
 * from the running node version.
 * <p>
 * Each index version constant has an id number, which for versions prior to 8.9.0 is the same as the release version
 * for backwards compatibility. In 8.9.0 this is changed to an incrementing number, disconnected from the release version.
 * <p>
 * Each version constant has a unique id string. This is not actually stored in the index, but is there to ensure
 * each index version is only added to the source file once. This string needs to be unique (normally a UUID,
 * but can be any other unique nonempty string).
 * If two concurrent PRs add the same index version, the different unique ids cause a git conflict, ensuring the second PR to be merged
 * must be updated with the next free version first. Without the unique id string, git will happily merge the two versions together,
 * resulting in the same index version being used across multiple commits,
 * causing problems when you try to upgrade between those two merged commits.
 * <h2>Version compatibility</h2>
 * The earliest compatible version is hardcoded in the {@link #MINIMUM_COMPATIBLE} field. Previously, this was dynamically calculated
 * from the major/minor versions of {@link Version}, but {@code IndexVersion} does not have separate major/minor version numbers.
 * So the minimum compatible version is hard-coded as the index version used by the first version of the previous major release.
 * {@link #MINIMUM_COMPATIBLE} should be updated appropriately whenever a major release happens.
 * <h2>Adding a new version</h2>
 * A new index version should be added <em>every time</em> a change is made to the serialization protocol of one or more classes.
 * Each index version should only be used in a single merged commit (apart from BwC versions copied from {@link Version}).
 * <p>
 * To add a new index version, add a new constant at the bottom of the list that is one greater than the current highest version,