Batch index executor: Don't fall back to interactive executor

Since I88ae7f4a background mergeability checks were replaced with
reindexing. To determine the executor for the batch reindexing, a
number of valid and deprecated configuration options are used. When
none of these options are set batch reindexing is falling back to
use the interactive executor.

This logic leads to severe performance degradation during git push
operation because ref-update listener is reindexing all open changes
on the target branch interactively. This degradation increases linearly
with number of open changes on the target branch.

Instead of falling back performing the batch reindexing operation
interactively, use batch thread pool with logical number of CPU cores.

Bug: issue 3363
Change-Id: I6890c4285a13683c050e7500bea5deb2dc50b6e0

gerrit-server/src/main/java/com/google/gerrit/server/index/IndexModule.java

@@ -114,7 +114,6 @@ public class IndexModule extends LifecycleModule {
   @Singleton
   @IndexExecutor(BATCH)
   ListeningExecutorService getBatchIndexExecutor(
-      @IndexExecutor(INTERACTIVE) ListeningExecutorService interactive,
       @GerritServerConfig Config config,
       WorkQueue workQueue) {
     if (batchExecutor != null) {
@@ -125,7 +124,7 @@ public class IndexModule extends LifecycleModule {
       threads = config.getInt("changeMerge", null, "threadPoolSize", 0);
     }
     if (threads <= 0) {
-      return interactive;
+      threads = Runtime.getRuntime().availableProcessors();
     }
     return MoreExecutors.listeningDecorator(
         workQueue.createQueue(threads, "Index-Batch"));