When a shard becomes search active then trigger a refresh instead of waiting for the next scheduled refresh.
The `IndexShard#awaitShardSearchActive(...)` method registers a refresh listener and then often waits for the refresh scheduler to trigger a refresh. By default this is one second. In order to avoid increasing the query time of the Search API, the mentioned method should trigger a refresh instead for waiting it to happen.

As part of this change we also need to disable the refresh scheduler completely. Otherwise we run at risk of running two refreshes next after each other. One triggered from making shard search active and one from the refresh scheduler.  



server/src/main/java/org/elasticsearch/index/shard/IndexShard.java
active.set(true);
        }
        
        
        onSettingsChanged();
    }
    /**
     * Returns the maximum sequence number of either update or delete operations have been processed in this shard
     * or the sequence number from {@link #advanceMaxSeqNoOfUpdatesOrDeletes(long)}. An index request is considered
     * as an update operation if it overwrites the existing documents in Lucene index with the same document id.
     * <p>
     * The primary captures this value after executes a replication request, then transfers it to a replica before
     * executing that replication request on a replica.
     */
    public long getMaxSeqNoOfUpdatesOrDeletes() {
        return getEngine().getMaxSeqNoOfUpdatesOrDeletes();
    }
    /**
     * A replica calls this method to advance the max_seq_no_of_updates marker of its engine to at least the max_seq_no_of_updates
     * value (piggybacked in a replication request) that it receives from its primary before executing that replication request.
     * The receiving value is at least as high as the max_seq_no_of_updates on the primary was when any of the operations of that
     * replication request were processed on it.
     * <p>
     * A replica shard also calls this method to bootstrap the max_seq_no_of_updates marker with the value that it received from
     * the primary in peer-recovery, before it replays remote translog operations from the primary. The receiving value is at least
     * as high as the max_seq_no_of_updates on the primary was when any of these operations were processed on it.
     * <p>
     * These transfers guarantee that every index/delete operation when executing on a replica engine will observe this marker a value
     * which is at least the value of the max_seq_no_of_updates marker on the primary after that operation was executed on the primary.