getRemoteClusterClient does not need a ThreadPool

[DaveCTurner]

Following #104536 this argument is now unused.

[elasticsearchmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[rjernst]

What is the harm in being explicit here? Piggy-backing access to services from other services has made refactoring in the past especially difficult.

[DaveCTurner]

Ultimately there's no need for a remote-cluster client to have a threadpool at all, see #104536, this is really just to pre-empt some of the noise from that PR.

In fact org.elasticsearch.client.internal.support.AbstractClient#threadPool is itself only there to pass on to other services, it's not used within the client at all. I'd love to get rid of that too.

[rjernst]

The number of places extracting threadpool from client is daunting...though the two main uses seem to be (from a skim of findings in intellij) constructing another client, and getting at the threadcontext. For the latter, I wonder if we should rethink how to get at threadcontext. It's only loosely related to threadpool, in that we create a single threadpool, and it has to do with threading. You could imagine the threadcontext itself being available as a static or threadlocal, or better yet, something like the new ScopedValues that are in preview in newer versions of Java.

With that all said, I realize the above is not trivial, so I think this is ok as a stepping stone.

[DaveCTurner]

On reflection if we do #104536 first then that removes the objections to this change, because that PR renders this ThreadPool arg unused.