Edges between pseudo nodes are typically artifacts of imperfect
connection tracking, e.g. when VIPs and NAT traversal are in use.

So lets filter them out.

filter out unconnected pseudo nodes just once, at the end

This eliminates the awkward distinction between ProcessRenderer and
ColorConnectedProcessRenderer.

It also ensures that processes resulting from direct rendering of the
process topology (/api/topology/processes is invoking
ProcessWithContainerNameRenderer and /api/topology/processes-by-name
is invoking ProcessNameRenderer) are colored and hence summarising
them correctly sets the 'linkable' property. This was the behaviour
prior to the revamping of the rendering pipeline. However, it doesn't
actually make a practical difference since process detail panels only
show other processes as connection endpoints, and these are always
marked linkable anyway.

It's now done via a special filter, once, after all other filters have
been applied.

Some tests need updating since they were relying on ordinary filters
doing that filtering.

...rather than before. That way, nodes which become unconnected during
filtering are removed, which is what we want. ATM we are depending on
some 'unconnected' filtering inside every filter, which is expensive
and largely redundant. We should soon be able to remove that.

downside: 'unconnected' filtering is no longer memoised.

This is a step towards filtering unconnected nodes after all custom
filters have been applied.

so we can generalise the filter step in render.Render et al. That will
allow us to apply whole-topology filters in that step.

Instead of three passes
1. building a 'connected' node set
2. marking nodes from that set with a LatestMap entry
3. removing unmarked nodes

we just do two
1. building a 'connected' node set
2. removing nodes not in that set

This does entail duplication of the adjecency list pruning code from
FilterFunc.Apply. We will be able to eliminate that eventually, but
not just yet.

Also, we cannot get rid of ColorConnected completely;
ColorConnectedProcessRenderer uses it to mark nodes, and that
information is required by detailed.processNodeSummary to determine
whether a process in the details panel can be rendered as a link.

optimisation: faster knownServiceCache

We use an LRU cache implementation that is keyed on strings, which
avoids conversion to/from interface and the memory allocation that
entails.

optimisation: make Memoise(Memoise(...)) only memoise once

All outputs of Memoise() are fixpoints to the function, i.e. feeding
them as inputs to the function just returns them.

We don't hit this optimisation in current code but have had instances
in the past.

make render.ResetCache() reset all caches

Correctly show whether there are new images or not.

so that benchmarks yield more consistent results.

Rewrite more Map-Reduces as Renderers to save garbage

It's more efficient as many input Nodes map onto a few hosts.

This is more efficient as there are typically many fewer names than
processes.

This is preparatory to future refactorings: all existing calls are to
Endpoints which have no children and where we don't want a Counter.

We make addChildAndChildren an obvious extension of addChild even
though it adds a dead code path (we never call addChildAndChildren
with an endpoint).

Filtering nodes *adds* to the Filtered count.

Decorators, begone!

to de-decorate

instead of constructing temporary Filter renderers.

This also makes clearer what is going on.

so it becomes accessible w/o having to construct a Filter renderer.

Decorators were just a complicated way of constructing filters.

Expand the app's k8s namespace calculation

find returns 'undefined' not 'null'!

and rename existing IsConnected const to IsConnectedMark

Decoration is in fact quite a simple process that is applied on entry
to rendering: we take a base renderer, transform it with a decorator,
and then render a report with it. The new render.Decorate() function
does exactly that.

There is one exception. When rendering an individual node, e.g. for
showing its details panel in the UI, we must not lose the node during
decoration. That requires some special logic, which previously resided
in the PreciousNodeRenderer, and now lives in handleNode.

pass render filters and maps by value rather than reference

to include recently added k8s types.

This is all rather inefficient. See #2945.

They are small and don't carry mutable state, so there is no point
passing them by reference.

Parsing optimisations

Pass in a slice on the stack instead of allocating one on the heap:
reduces garbage, hence makes the program run faster

Also apply knowledge that critbitgo will do an append() with one extra
byte, so we do that allocation up-front too.  This is innocuous should
we stop using critbitgo or should its internals change.