Makes services the initial topology if available

[foot]

• Otherwise reverts to containers

Fixes #1809

[rade]

Otherwise reverts to containers

The prioritisation should be services -> deployments -> replica sets -> pods -> containers. Says @tomwilkie.

[foot]

Cool, will update

[davkal]

Code looks good.

Implementation-nit: priority should be driven by backend, so that when new topos are added, UI does not have to be involved.

UX-nit: If Services is the most important one, it should be at the top. Any introduction of priority ordering trumps representation model ordering (lower topos are groupings of higher topos). This needs to be changed in the backend.

[davkal]

priority should be driven by backend, so that when new topos are added, UI does not have to be involved.

Actually, we should put this up for discussion in the next meeting.

[davkal]

Can't we make service the main topo?

[davkal]

If we cant completely flip the order, I'd say let's stick to the original one.

[foot]

Node type, followed by its aggregates in order of most interest breaks strict "spatial alignment" w/ the priorities we've set up but I think it still works. If no aggs fall back to basic type.

[davkal]

I mostly have a problem with a sub-menu entry being the most important one (decided by priority). I feel that it makes the menu harder to grok.
An alternative would be dynamic prio ordering in the backend, so that the default one is the top one.