### Elasticsearch Version

8.10

### Installed Plugins

_No response_

### Java Version

_bundled_

### OS Version

Darwin michaels-mbp.lan 22.6.0 Darwin Kernel Version 22.6.0: Fri Sep 15 13:41:28 PDT 2023; root:xnu-8796.141.3.700.8~1/RELEASE_ARM64_T6000 arm64

### Problem Description

Cross cluster searches done with `ccs_minimize_roundtrips=true` (the default in Kibana as of version 8.10) inappropriately marks searches on remote clusters as "failed" or "skipped" when there are no shards to search (e.g., when that index is not present on the remote cluster). Those clusters should instead be reporting as successful. See "Steps to Reproduce" section for an example of correct vs. incorrect behavior.

This bug causes: https://github.com/elastic/elasticsearch/issues/100311

### Steps to Reproduce

Do a cross-cluster where one or more of the remote clusters lacks an index and query with ccs_minimize_roundtrips=true.

Example:

```
POST *,remote*:blog*/_async_search?ccs_minimize_roundtrips=true
{
  "size": 1,
  "query": {
    "match_all": {}
  }
}  
```

Result:

```
    "_clusters": {
      "total": 3,
      "successful": 1,
      "skipped": 1,
      "running": 0,
      "partial": 0,
      "failed": 1,
      "details": {
        "(local)": {
          "status": "successful",
          "indices": "*",
          "took": 24,
          "timed_out": false,
          "_shards": {
            "total": 2,
            "successful": 2,
            "skipped": 0,
            "failed": 0
          }
        },
        "remote2": {
          "status": "skipped",
          "indices": "blog*",
          "took": 2,
          "timed_out": false,
          "_shards": {
            "total": 0,
            "successful": 0,
            "skipped": 0,
            "failed": 0
          }
        },
        "remote1": {
          "status": "failed",
          "indices": "blog*",
          "took": 0,
          "timed_out": false,
          "_shards": {
            "total": 0,
            "successful": 0,
            "skipped": 0,
            "failed": 0
          }
        }
      }
    },
```

The correct response (which you get with ccs_minimize_roundtrips=false) should be:

```
   "_clusters": {
      "total": 3,
      "successful": 3,
      "skipped": 0,
      "running": 0,
      "partial": 0,
      "failed": 0,
      "details": {
        "(local)": {
          "status": "successful",
          "indices": "*",
          "took": 21,
          "timed_out": false,
          "_shards": {
            "total": 2,
            "successful": 2,
            "skipped": 0,
            "failed": 0
          }
        },
        "remote2": {
          "status": "successful",
          "indices": "blog*",
          "took": 16,
          "timed_out": false,
          "_shards": {
            "total": 0,
            "successful": 0,
            "skipped": 0,
            "failed": 0
          }
        },
        "remote1": {
          "status": "successful",
          "indices": "blog*",
          "took": 16,
          "timed_out": false,
          "_shards": {
            "total": 0,
            "successful": 0,
            "skipped": 0,
            "failed": 0
          }
        }
      }
    },
```



### Logs (if relevant)

_No response_
server/src/main/java/org/elasticsearch/action/search/TransportSearchAction.java
* "now" to an index name). Another clock is needed for measuring how long a search operation
     * took. These two uses are at odds with each other. There are many issues with using a real
     * clock for measuring how long an operation took (they often lack precision, they are subject
     * to moving backwards due to NTP and other such complexities, etc.). There are also issues with
     * using a relative clock for reporting real time. Thus, we simply separate these two uses.
     */
    public record SearchTimeProvider(long absoluteStartMillis, long relativeStartNanos, LongSupplier relativeCurrentNanosProvider) {
        /**
         * Instantiates a new search time provider. The absolute start time is the real clock time
         * used for resolving index expressions that include dates. The relative start time is the
         * start of the search operation according to a relative clock. The total time the search
         * operation took can be measured against the provided relative clock and the relative start
         * time.
         *
         * @param absoluteStartMillis          the absolute start time in milliseconds since the epoch
         * @param relativeStartNanos           the relative start time in nanoseconds
         * @param relativeCurrentNanosProvider provides the current relative time
         */
        public SearchTimeProvider {}
        public long buildTookInMillis() {
            return TimeUnit.NANOSECONDS.toMillis(relativeCurrentNanosProvider.getAsLong() - relativeStartNanos);
        }
    }
    @Override
    protected void doExecute(Task task, SearchRequest searchRequest, ActionListener<SearchResponse> listener) {
        executeRequest((SearchTask) task, searchRequest, listener, AsyncSearchActionProvider::new);
    }
    void executeRequest(
        SearchTask task,
        SearchRequest original,