We replace the existing data structure with a simpler one that
only specifies how to get the parent label, which is the only
part of the Parent struct that can't be generated from the node info alone.
Future work: Standardize this concept of a label and put it in the topology instead.
Though that already exists...so just use it?
The default sets the node label to the node ID.
This is likely to not look very good, but the intent is that it creates an obvious problem,
ie. that the node ID is being used as the label, rather than a silent omission or more subtle problem.
Possible future work:
* For single-component IDs, extract the component automatically and use that instead.
* Instead of functions, in simple cases just have a LUT by topology with common behaviours like
'stack = true or false', 'label = this key in node.Latest'
The latter opens up to eventually moving this info inside the report itself ala topology templates,
or at least centralizing it in the source.
Currently, if a topology does not have any specific info in nodeSummariesByID,
any children of the node that belong to that topology will be silently omitted.
This change adds a default behaviour for such topologies, with no special columns
but at least it is displayed at all.
Unlisted topologies are displayed after all listed ones, in arbitrary order.
Note that completely bogus or other special cases (eg. topology = Pseudo) still will not
be displayed as report.Topology() will fail.
This gives us a single source of truth in a variety of situations where we want to
know what view to direct a user to in order to 'open' a particular node.
I wanted to put this in app/api_topologies where the views are defined, but that creates
a circular import.
By reducing the number of times we refer to every topology by name line by line,
we make it easier to add new topologies, reduce the risk of bugs where a topology is not listed,
and reduce the risk of the repeated lines getting out of sync with each other.
We introduce two new methods to assist this:
WalkPairedTopologies, a modified WalkTopologies that gives the called function
the same topology from two reports. This is used, for example, to implement Copy and Merge.
TopologyMap, which returns a map of all topologies by name. This is then used to implement all other methods.
This leaves only 4 instances of listing topologies:
In the consts at the top of the file, to give it a name
In the struct itself
In the constructor, where we need to set per-topology settings
In TopologyMap
* remove randomness as far as possible
* make listener to close connections
* report time in a csv-friendly format
* remove tools from README
* rename time-scope-probe -> time-scope-probe-proc
* add time-scope-probe-cgroup
