Run FetchHealthInfoCacheAction on transport thread (elastic#139285)

The most expensive thing that
`FetchHealthInfoCacheAction.TransportAction` does is `Map.copyOf` of
maps that are keyed by node ID (i.e. limited size). That can run on the
transport thread without any risk of blocking the thread too long.

We've seen issues where the `management` thread pool on the health node
is being blocked by something else, causing health logs (and API calls)
to be stuck/slow. To offer a more consistent health experience, we make
this action run on the transport thread instead of the management one.

Author: nielsbauman

server/src/main/java/org/elasticsearch/health/node/FetchHealthInfoCacheAction.java

@@ -18,6 +18,7 @@
 import org.elasticsearch.cluster.service.ClusterService;
 import org.elasticsearch.common.io.stream.StreamInput;
 import org.elasticsearch.common.io.stream.StreamOutput;
+import org.elasticsearch.common.util.concurrent.EsExecutors;
 import org.elasticsearch.health.node.action.HealthNodeRequest;
 import org.elasticsearch.health.node.action.TransportHealthNodeAction;
 import org.elasticsearch.injection.guice.Inject;
@@ -114,7 +115,7 @@ public TransportAction(
                 actionFilters,
                 FetchHealthInfoCacheAction.Request::new,
                 FetchHealthInfoCacheAction.Response::new,
-                threadPool.executor(ThreadPool.Names.MANAGEMENT)
+                EsExecutors.DIRECT_EXECUTOR_SERVICE
             );
             this.nodeHealthOverview = nodeHealthOverview;
         }