[InfraUI] Use container IDs instead of names for grouping, filtering and linking

[roncohen]

container.name and kubernetes.pod.name are not guaranteed to be unique across an installation. We'll need to use ids when grouping, filtering and linking to other pages across the logs ui, waffle map, node details and eventually the APM UI. See also #25939.

It would still be convenient if the Node details page showed container.name or kubernetes.pod.name as a friendly way to identify the current node, instead of showing only the raw ID. Since this issue is about changing the UIs to use IDs for grouping, filtering and linking, showing the friendly names would probably require the UI to have functionality to look up the name from a given ID.

Rough checklist to get us started (feel free to add/edit):

waffle map

• grouping by container.id/kubernetes.pod.uid
• allow linking to filtered/grouped waffle map by container.id/kubernetes.pod.uid
• links to node detail/logs should use container.id/kubernetes.pod.uid

logs

• allow linking by container.id/kubernetes.pod.uid
• show friendly name when given container.id/kubernetes.pod.uid

node details

• show friendly name when given container.id/kubernetes.pod.uid
• allow linking by container.id/kubernetes.pod.uid

[elasticmachine]

Pinging @elastic/infrastructure-ui

[exekias]

Created elastic/beats#9360 on the Beats side to make sure kubernetes.pod.uid is always available

[simianhacker]

@skh I'm thinking about modifying the metadataByNode endpoint to include more metadata about each node. For example, now that we are using the docker.container.id and kubernetes.pod.uid we will need a way to look up the human readable name. This would change the format of the response to something like:

  "A feature entry for a node."
  type InfraNodeFeature {
    name: String!
    source: String!
  }

  "Metadata about the node"
  type InfraNodeMetadata {
    id: ID!
    name: String!
    features: [InfraNodeFeature!]!
  }

  extend type InfraSource {
    "A hierarchy of metadata entries by node"
    metadataByNode(nodeName: String!, nodeType: InfraNodeType!): InfraNodeMetadata!
  }

Then we can use this as an alias in other GraphQL queries where we are going to need more metadata. I know at some point we are going to need to lookup things like OS, architecture, etc so I foresee more fields being added like name.

Does features work for a key? I know we had some conversations about what to name this data so I wanted to run that by you to see if it would work. Also any thoughts on the approach would be appreciated.