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
assert newRouting.primary() == false
                    : "primary routing is active, but local shard state isn't. routing: " + newRouting + ", local state: " + state;
                throw new IllegalIndexShardStateException(shardId, state, "master processed stale shard-started event, failing shard");
            }
            persistMetadata(path, indexSettings, newRouting, currentRouting, logger);
            final CountDownLatch shardStateUpdated = new CountDownLatch(1);
            if (newRouting.primary()) {
                if (newPrimaryTerm == pendingPrimaryTerm) {
                    if (currentRouting.initializing() && currentRouting.isRelocationTarget() == false && newRouting.active()) {
                        
                        replicationTracker.activatePrimaryMode(getLocalCheckpoint());
                        ensurePeerRecoveryRetentionLeasesExist();
                    }
                } else {
                    assert currentRouting.primary() == false : "term is only increased as part of primary promotion";
                    /* Note that due to cluster state batching an initializing primary shard term can failed and re-assigned
                     * in one state causing it's term to be incremented. Note that if both current shard state and new
                     * shard state are initializing, we could replace the current shard and reinitialize it. It is however
                     * possible that this shard is being started. This can happen if:
                     * 1) Shard is post recovery and sends shard started to the master
                     * 2) Node gets disconnected and rejoins
                     * 3) Master assigns the shard back to the node
                     * 4) Master processes the shard started and starts the shard