Always use a thread pool for interactive indexing

The problem is that when you cancel an ssh command, the thread handling
the command gets interrupted. If it happens that the thread is
interrupted while it's updating the index, this will close the index
writer and any subsequent operations that need indexing will fail.

In order to protect Lucene index writer from any possible thread
interruption, we need to delegate the index writing to a separate thread
pool and never cancel or interrupt threads from that thread pool.

For background indexing, Gerrit already uses a thread pool but for
interactive indexing, Gerrit optionally support using a thread pool and
the default configuration is not using one.

Remove the possibility to do interactive indexing in the same thread as
the operation to prevent Lucene index writer from being interrupted.

Bug: Issue 3885
Change-Id: Ic20cd1caa827a205a83417eff7a619133bc2450c

Documentation/config-gerrit.txt

@@ -2400,10 +2400,10 @@ By default, `LUCENE`.
 
 [[index.threads]]index.threads::
 +
-Number of threads to use for indexing in normal interactive operations. If set
-to 0, indexing will be done in the same thread as the interactive operation.
+Number of threads to use for indexing in normal interactive operations.
 +
-Defaults to 0 if not set, or set to a negative value.
+If not set or set to a negative value, defaults to 1 plus half of the number of
+logical CPUs as returned by the JVM.
 
 [[index.batchThreads]]index.batchThreads::
 +

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

@@ -140,7 +140,7 @@ public class IndexModule extends LifecycleModule {
       threads = config.getInt("index", null, "threads", 0);
     }
     if (threads <= 0) {
-      return MoreExecutors.newDirectExecutorService();
+      threads = Runtime.getRuntime().availableProcessors() / 2 + 1;
     }
     return MoreExecutors.listeningDecorator(
         workQueue.createQueue(threads, "Index-Interactive"));