Today we deserialize and handle all responses from remote clusters on the transport thread. Some of these responses can be sizeable, or require nontrivial work to handle, so we need to move this work to different threads. https://github.com/elastic/elasticsearch/pull/97922 introduces a facility for doing so, and forks some work, but in that PR we could not decide whether to handle CCS-related responses on the `SEARCH` or `SEARCH_COORDINATION` pool. In order to make progress we left this work on the transport worker for now, but we think this is a bug and this computation should be forked elsewhere. Opening this issue to track that followup work.

Once it's decided where to run this work, here's the only bit that needs changing:

https://github.com/elastic/elasticsearch/blob/f4e3113ad00541f084b69664c6476c8fcf737386/server/src/main/java/org/elasticsearch/action/search/TransportSearchAction.java#L470-L471

server/src/main/java/org/elasticsearch/action/search/TransportSearchAction.java
for (SearchSourceBuilder.IndexBoost ib : source.indexBoosts()) {
            Index[] concreteIndices = indexNameExpressionResolver.concreteIndices(
                clusterState,
                searchRequest.indicesOptions(),
                ib.getIndex()
            );
            for (Index concreteIndex : concreteIndices) {
                concreteIndexBoosts.putIfAbsent(concreteIndex.getUUID(), ib.getBoost());
            }
        }
        return Collections.unmodifiableMap(concreteIndexBoosts);
    }
    /**
     * Search operations need two clocks. One clock is to fulfill real clock needs (e.g., resolving
     * "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.
     */
    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