Clean up thread pool usage (#11681)

Using an unbound LinkedBlockingQueue means you *have* to set core and max core thread pool size the same, as they will never go above the minimum pool size by just passing them through. So this fixes the async command executor pool to actually use 2 threads, and also cleans up other usage to be explicitly "fixed" thread pool sizes, and splits off one more in Minecraft's Util class

patches/server/Async-command-map-building.patch

@@ -17,19 +17,14 @@ index 0000000000000000000000000000000000000000..00000000000000000000000000000000
          // CraftBukkit start
          // Register Vanilla commands into builtRoot as before
 +        // Paper start - Perf: Async command map building
-+        COMMAND_SENDING_POOL.execute(() -> {
-+                this.sendAsync(player);
-+        });
++        COMMAND_SENDING_POOL.execute(() -> this.sendAsync(player));
 +    }
 +
-+    public static final java.util.concurrent.ThreadPoolExecutor COMMAND_SENDING_POOL = new java.util.concurrent.ThreadPoolExecutor(
-+        0, 2, 60L, java.util.concurrent.TimeUnit.SECONDS,
-+        new java.util.concurrent.LinkedBlockingQueue<>(),
++    public static final java.util.concurrent.ExecutorService COMMAND_SENDING_POOL = java.util.concurrent.Executors.newFixedThreadPool(2,
 +        new com.google.common.util.concurrent.ThreadFactoryBuilder()
 +            .setNameFormat("Paper Async Command Builder Thread Pool - %1$d")
 +            .setUncaughtExceptionHandler(new net.minecraft.DefaultUncaughtExceptionHandlerWithName(net.minecraft.server.MinecraftServer.LOGGER))
-+            .build(),
-+        new java.util.concurrent.ThreadPoolExecutor.DiscardPolicy()
++            .build()
 +    );
 +
 +    private void sendAsync(ServerPlayer player) {