Fix docs for transport_worker hot threads (elastic#96346)

Backports the docs changes from elastic#96315, reflecting the change introduced
in elastic#90482, but adjusting them slightly to reflect the different
behaviour in earlier versions.

Co-authored-by: Elastic Machine <[email protected]>

Author: DaveCTurner

docs/reference/modules/network/threading.asciidoc

@@ -63,7 +63,7 @@ reported like this:
 
 [source,text]
 ----
-   100.0% [cpu=0.0%, other=100.0%] (500ms out of 500ms) cpu usage by thread 'elasticsearch[instance-0000000004][transport_worker][T#1]'
+   0.0% [cpu=0.0%, idle=100.0%] (500ms out of 500ms) cpu usage by thread 'elasticsearch[instance-0000000004][transport_worker][T#1]'
      10/10 snapshots sharing following 9 elements
        [email protected]/sun.nio.ch.EPoll.wait(Native Method)
        [email protected]/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:118)
@@ -78,10 +78,10 @@ reported like this:
 
 Note that `transport_worker` threads should always be in state `RUNNABLE`, even
 when waiting for input, because they block in the native `EPoll#wait` method.
-This means the hot threads API will report these threads at 100% overall
-utilisation. This is normal, and the breakdown of time into `cpu=` and `other=`
-fractions shows how much time the thread spent running and waiting for input
-respectively.
+The `idle=` time reports the proportion of time the thread spent waiting for
+input, whereas the `cpu=` time reports the proportion of time the thread spent
+processing input it has received. If the thread was seen using absolutely no
+CPU then it will report `0.0% [cpu=0.0%, idle=0.0%]`.
 
 If a `transport_worker` thread is not frequently idle, it may build up a
 backlog of work. This can cause delays in processing messages on the channels