feat(scheduler): set scheduling-class label on mutated pods - #2621

What this PR does

Extends the lineage-controller-webhook so that, on every Pod it mutates with a SchedulingClass, it also sets a label of the same name (in addition to the existing annotation).

Today, when a SchedulingClass is in effect on a tenant, the webhook injects:

• spec.schedulerName: cozystack-scheduler
• annotation scheduler.cozystack.io/scheduling-class: <name>

This is enough for the cozystack-scheduler to look the class up and apply its nodeAffinity, nodeSelector, and topology rules. However, it is not enough to write a SchedulingClass whose spec.podAffinity rules labelSelector targets pods across multiple applications, because labelSelector matches labels and not annotations.

This PR adds the label, leaving the annotation untouched for backward compatibility:

podLabels := obj.GetLabels()
if podLabels == nil {
    podLabels = make(map[string]string)
}
podLabels[schedulerapi.SchedulingClassLabel] = schedulingClass
obj.SetLabels(podLabels)

The constants SchedulingClassLabel and SchedulingClassAnnotation exported by github.com/cozystack/cozystack-scheduler/pkg/apis/v1alpha1 already share the same value (scheduler.cozystack.io/scheduling-class), so no new key is introduced.

Why this is useful: a single SchedulingClass can now express "co-locate every pod that uses me at the same topology" with a rule like:

apiVersion: cozystack.io/v1alpha1
kind: SchedulingClass
metadata:
  name: co-region-prod
spec:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchLabels:
          scheduler.cozystack.io/scheduling-class: co-region-prod
      topologyKey: topology.kubernetes.io/region

When several applications share this class, the second-and-later pods will be constrained to the region the first one landed on — without hard-coding any region in the class itself.

Tests

Adds a webhook_test.go (none existed in the package). Five unit tests, using clientfake.NewClientBuilder + dynamicfake.NewSimpleDynamicClientWithCustomListKinds, cover:

• Label, annotation, and schedulerName are all set when a class exists.
• Existing pod labels are preserved (no clobbering).
• Non-Pod objects are a no-op.
• Pods in a namespace without a scheduling-class label are a no-op.
• Pods whose referenced SchedulingClass CR does not exist are a no-op (the existing defensive behavior, preserved).

Release note

feat(scheduler): the lineage-controller-webhook now sets a scheduler.cozystack.io/scheduling-class label on mutated pods (in addition to the existing annotation), enabling SchedulingClass authors to write podAffinity rules that match pods across applications.

Summary by CodeRabbit

• New Features
  • Pods with a valid scheduling class now receive its label alongside the scheduler configuration and annotation.
  • Existing Pod labels are preserved when the scheduling-class label is added.
• Bug Fixes
  • Scheduling-class settings are applied only when the namespace references a scheduling class that exists. Non-Pods and namespaces without a scheduling-class label are left unchanged.