Avoid walking the complete list of search contexts on shard creation

This I found in the many-shards benchmark during some manual testing.
Creating indices slows down measurably when there's concurrent searches
going on. Interestingly enough, the bulk of the cost is coming from this
hook. This makes sense to some extend because the map can quickly grow
to a massive size as it scales as O(shards_searched_on_average *
concurrent_searches) and a CHM generally is anything but cheap to
iterate over.

Author: original-brownbear

server/src/main/java/org/elasticsearch/search/SearchService.java

@@ -29,6 +29,7 @@
 import org.elasticsearch.action.support.TransportActions;
 import org.elasticsearch.cluster.ProjectState;
 import org.elasticsearch.cluster.metadata.IndexNameExpressionResolver.ResolvedExpression;
+import org.elasticsearch.cluster.routing.RecoverySource;
 import org.elasticsearch.cluster.routing.ShardRouting;
 import org.elasticsearch.cluster.service.ClusterService;
 import org.elasticsearch.common.CheckedSupplier;
@@ -488,7 +489,7 @@ public void beforeIndexShardCreated(ShardRouting routing, Settings indexSettings
         // to stop searches to restore full availability as fast as possible. A known scenario here is that we lost connection to master
         // or master(s) were restarted.
         assert routing.initializing();
-        if (routing.isRelocationTarget() == false) {
+        if (routing.isRelocationTarget() == false && routing.recoverySource() != RecoverySource.EmptyStoreRecoverySource.INSTANCE) {
             freeAllContextsForShard(routing.shardId());
         }
     }