[FEA] Add a Kubernetes node-label topology provider for Slinky deployments

[dmitsh]

Description

Many cloud providers expose physical topology information in their managed Kubernetes offerings through node labels. Kubernetes-native schedulers can consume these labels directly, but Slurm-on-Kubernetes systems such as Slinky require a generated topology.conf stored in a ConfigMap and cannot consume Kubernetes node labels directly.

Topograph should support this use case with a dedicated provider that discovers topology from configurable Kubernetes node labels. This provider is intended to eventually supersede the existing dra provider.

Proposed behavior

• Accept an ordered list of topology label keys, from the tier closest to the node to the furthest tier.
• Read the configured labels from Kubernetes Nodes and translate them into Topograph’s canonical topology graph.
• Treat missing or invalid label values according to a clearly defined validation policy.
• Integrate with the existing Node Observer so topology is regenerated when:
  • a Node is added or deleted;
  • a relevant topology label changes; or
  • a Node readiness or status change affects whether it should be included.
• Allow the Slinky engine to render the resulting graph as topology.conf and update the configured Slinky ConfigMap.
• Preserve the provider/engine boundary: the provider discovers topology, while the Slinky engine remains responsible for writing scheduler-specific configuration.

Acceptance criteria

• Users can configure one or more Kubernetes node-label keys as topology tiers.
• Nodes are grouped correctly for both single-tier and multi-tier topologies.
• Adding or deleting a Node triggers regeneration.
• Changing a configured topology label triggers regeneration.
• Relevant Node status changes trigger regeneration.
• Unrelated Node label changes do not trigger unnecessary regeneration.
• The generated Slinky ConfigMap reflects the current eligible Node population and topology.
• Configuration, validation, and operational behavior are documented.
• Tests cover topology construction and regeneration triggers.

Follow-up

Once the new provider offers equivalent or broader functionality, the dra provider can be deprecated and removed through the normal compatibility and release-note process.