TransportBroadcastByNodeAction does O(#shards) work on transport worker thread

[DaveCTurner]

Three interrelated issues here:

• TransportBroadcastByNodeAction derivatives are typically executed via NodeClient which bypasses the TransportService and therefore does not respect (or even know about) the executor parameter which would fork. This means that the coordination work, including grouping all the shards by node, happens on the calling thread. When executed from the REST layer, that's a transport worker. This is NodeClient executes transport actions without forking #97916, but until that's fixed we need a workaround.

• The node-level responses are deserialised and processed on the receiving transport worker too.

• Several of these actions use SAME for their executor, bypassing the forking that does exist today.

Relates #77466

[DaveCTurner]

I caught this when looking at a large (90k+ shards) cluster which would occasionally log warnings about slow execution of _cat/shards and _stats when under load.

[elasticsearchmachine]

Pinging @elastic/es-distributed (Team:Distributed)