the full type output by vars is now:
(list [cord (list [cord (list [cord @])])])
it's a mouthful, but a consistent mouthful. the first layer of the list
is the IO driver name, nam_m. the second layer is the instance name,
either %all or some driver-relevant identifier (e.g. http instance.) the
third layer is the list of labels and values.
This actually raises difficult questions about the schema for the /vars
peel. One level of nesting makes sense to aggregate per IO driver, but
multiple levels is confusing.
The current output is extremely unprincipled: you just have to know that
there are multiple http servers and handle the output accordingly.
Options would be:
1. collapse the ambiguity to the top level, i.e. 'http-0i8080',
'http-global', etc.
2. collapse the ambiguity to the inner level, i.e. '0i8080-connections'.
3. create a proper recursive data type that e.g. uses an $each.
3b. send some kind of schema.
5. recognize that we have entered a terrifying hall of mirrors and back
out the entire approach of nested metrics in favor of just a bigass
flat list of labels with values like borgmon does.
tid was accidentally getting set to the name of the output mark. As we
don't currently support cancelling threads, there is no reason to
maintain the originally-intended correspondence between tid and conn
request-id.
Take the opportunity to clean up indentation somewhat.
Also strips out `$` from khan top-level comment.
There are arguments for keeping $crag in lull, and on the other side for
moving $cast to arvo. This seemed like the most reasonable approach.
