Improve the prototype's performance with an additional thread pool.

While regular blaze uses 2 different instances of QueueVisitor with 2 different thread pool sizes for loading/analysis and execution, with merged Skyframe phases we have to use the same instance. Therefore, it caused a serious performance regression with the existing version of the prototype: the number of threads used for the loading/analysis phase was just too low for the execution phase.

To fix that, we add another ExecutorService with an appropriate thread pool size (equals to the value of --jobs) to the instance of QueueVisitor. This additional ExecutorService is reserved for the evaluation of "Execution phase" SkyKeys e.g. ActionLookupData or ArtifactNestedSetKey.

PiperOrigin-RevId: 400977343
diff --git a/src/main/java/com/google/devtools/build/lib/analysis/BuildView.java b/src/main/java/com/google/devtools/build/lib/analysis/BuildView.java
index b0c9dec..ea261a9 100644
--- a/src/main/java/com/google/devtools/build/lib/analysis/BuildView.java
+++ b/src/main/java/com/google/devtools/build/lib/analysis/BuildView.java
@@ -203,7 +203,8 @@
       TopLevelArtifactContext topLevelOptions,
       ExtendedEventHandler eventHandler,
       EventBus eventBus,
-      boolean includeExecutionPhase)
+      boolean includeExecutionPhase,
+      int mergedPhasesExecutionJobsCount)
       throws ViewCreationFailedException, InvalidConfigurationException, InterruptedException {
     logger.atInfo().log("Starting analysis");
     pollInterruptedStatus();
@@ -394,7 +395,8 @@
                 topLevelOptions,
                 keepGoing,
                 loadingPhaseThreads,
-                viewOptions.cpuHeavySkyKeysThreadPoolSize);
+                viewOptions.cpuHeavySkyKeysThreadPoolSize,
+                mergedPhasesExecutionJobsCount);
       }
     } finally {
       skyframeBuildView.clearInvalidatedActionLookupKeys();