Add connection tables to details panel

[tomwilkie]

Part of #680, Fixes #378, Fixes #1111

This change also:

• Makes RenderableNode.Children a set of RenderableNodes, not Nodes
• Puts pseudo nodes back into the container's view (makes more sense to show connections now we have shapes) (This needed more work - Put pseudo nodes back into the container's view  #1123)

TODO:

• make it sort by count, by default
• change table ID as per davkal's request
• make connection work to/from the internet node
• figure out why the memoisation causes the test to fail
• testing / coverage
• add real nodes to the table
• figure out why inbound count != outbound count for self-connections
• better table for the internet node
• use reverse dns info (Use reverse DNS info #1121)

[davkal]

How about making connections a toplevel node field:

{
metadata,
metrics,
connections: [
  {
    id: "out",
    label: "Outgoing Connections",
    columns: [{id: "label", label: "Remote"}, {id: "port", label: "Port"}, {id: "count", label: "Count"}}],
    items:[{id: <nodeId>, label: <nodeLabel>, port: <port>, count: <count>, topologyId: <topologyId>}, ...]
  },
  {id: in, ...}
]}

[tomwilkie]

@davkal I eventually want the rows to link to other objects in the topology (ie link to the other container talking to this one) like the other children tables. Links will always be within the current view. Can you update your datastructure for this? I'm hoping links will always be possible, but you might want to make them optional.

[davkal]

Alternatively we can model connections as a nodes table, i.e. wrapping ports as metadata (typed as int to make it sortable as a number) and counts wrapped as a metric:

{
metadata,
metrics,
children,
connections: [{
    id: "out",
    label: "Outgoing Connections",
    columns: [{id: "label", label: "Remote"}, {id: "port", label: "Port"}, {id: "count", label: "Count"}}],
    nodes: [{
      id: <nodeId>,
      label: <nodeLabel>,
      topologyId: <topologyId>,
      metadata: [{port: <port>, type: "number"}]
      metrics: [{count: <count>}]
    }, ...]
  },
  {id: in, ...}

[davkal]

topologyId: "endpoint-incoming" needs to be id: "endpoint-incoming". topologyId is something like processes that will be used together with a node's id to build a deeplink.

[paulbellamy]

still quite a bit of tricky string-munging code shared between the incoming connections and outgoing connection aggregators.

[paulbellamy]

Connections Fr... is not a great table name.

Edit: When you sort by that column, both just become Connections ...

[paulbellamy]

I guess no luck on converting the endpoints to their respective nodes in the relevant topology?

[tomwilkie]

I guess no luck on converting the endpoints to their respective nodes in the relevant topology?

Time constraint I'm afraid. Will do it next sprint.

[paulbellamy]

Aside from a few naming things and refactoring (if possible), this LGTM.

[tomwilkie]

@paulbellamy I think I've addressed all the feedback, and got it working for the internet node. Its a bit of a hack. I think we should punt this form 0.13 and finish it properly. Thoughts?

[tomwilkie]

Also think the internet is going to need a custom table (for outgoing connections):

[tomwilkie]

Going to hold this until #566 is merged. Also need @pidster input on the table for the internet node(s).

[paulbellamy]

General approach seems fine. A couple naming and tidiness things.