[sled-agent] investigate tokio thread pool size

We should think about adjusting the default size of the tokio thread pool for sled-agent. By default tokio is spinning up n threads based on the number of CPUs it is able to see at startup - on a dogfood sled we see 100+ tokio worker threads and this will only increase with Turin based systems.

Another interesting note is that tokio seems to possibly be waking up all of its threads when there is work to do:

BRM42220057 # dtrace -n 'pid$target::pthread_cond_*:entry { @[probefunc] = count() } tick-10s { exit(0)}' -p 644
dtrace: description 'pid$target::pthread_cond_*:entry ' matched 10 probes
CPU     ID                    FUNCTION:NAME
 49  85759                        :tick-10s

  pthread_cond_clockwait                                            4
  pthread_cond_timedwait                                            4
  pthread_cond_signal                                             373
  pthread_cond_wait                                               398
  pthread_cond_broadcast                                        14051

It's unclear if this is causing any "thundering herd" type issues but it's worth looking into.

No file or test is named; start by locating the sled-agent Tokio runtime configuration and checking how its worker count is chosen. Reproduce the thread and wake-up behavior on a dogfood sled, then determine whether a smaller default is justified and document the resulting recommendation or change.