charts: implement rendering for --no-threads mode

This is a first stab at supporting --no-threads, which is a
little awkward because of how threads must still be followed to
maintain an awareness of the potential children processes of
threads.

So in libvmon there's a flag now for neglecting monitoring of
threads, while still following them.  This retains the same
libvmon topology as before, where threads were always monitored,
and threads still get their own vmon_proc_t instances in the
in-memory representation of the vmon_proc_t hierarchy.

What the libvmon flag changes is it prevents the vmon_proc_t
instances representing threads from allocating sampler states and
opening the various proc files used for sampling that information
from threads.  So it reduces the number of proc files held open
when there are threaded processes monitored, and saves some
memory allocation for eliding storage for those samples.

For the charts rendering side, since libvmon's representation is
essentially unchanged with --no-threads, and actually breaks some
assumptions rendering previously made about proc_ctxt's always
being allocated for any vmon_proc_t in the tree because
these allocations are suppressed when neglecting threads, there
needs to be an awareness of --no-threads mode and a pile of
conditional goo to prevent rendering the threads both
statistically/informationally and hierarchically.

This commit adds that goo to the charts rendering while
simultaneously actually wiring up this flag to libvmon.  On a
high level the primary facets of what this goo does are:

1. Suppress the effects of vmon_proc_t.is_thread nodes on the
   rendered hierarchy, keeping these rows invisible, preventing
   their impact on the row and depth variables, suppressing their
   counting towards row counts in snowflaking of subtrees, and
   suppressing their influence on the connectivity branches
   normally drawn to link siblings separated by threaded
   processes.

2. Bypass the usual ommission of rendering wchan and process
   state on multithreaded processes.  Normally we'd rely on the
   main thread's rendering of these fields, but when the threads
   aren't being shown, we'd like to still see at least a single
   wchan and state for that main thread in the still shown
   process' row.  But this is barely useful, you really need to
   see all the threads' wchans and states if you have any hope to
   understand what multithreaded processes are doing.

   I think this also highlights a shortcoming in that there's no
   obvious indicator showing which processes are multithreaded
   when --no-threads is in use.  A subsequent commit will likely
   add something like a [$threads_count] at the start of the
   Argv/~ThreadName field.

0 files changed, 0 insertions, 0 deletions