Hold AddonsLayer: suspend owned HelmReleases to block ConfigMap-triggered reconciles

[kishoregv]

When AddonsLayer.spec.hold: true, we often update shared ConfigMaps. Flux HelmReleases may still reconcile on those ConfigMap changes as their interval hits, even though the layer is on hold. This can push partial or unintended values into running releases.

• Change: When an AddonsLayer is put on hold, the controller sets spec.suspend=true on all HelmReleases owned by the layer and annotates them with kraan/suspended-by-hold: "true". This ensures Helm controller ignores ConfigMap/value changes while the layer is held. A Normal event is emitted with a count of suspended releases.
• Resume: When hold is removed, the AddonsLayer applies the latest manifests from the Git repo. Because the repo HR specs typically do not include suspend, the applied spec clears suspension and Helm controller reconciles the latest desired state.
• Logging/visibility:
  • Per-HelmRelease info log at V(1): “suspended HelmRelease due to layer hold”.
  • AddonsLayer event: “Suspended N HelmRelease(s) due to hold”.
  • Annotation allows operators to identify why a HR is suspended.

Acceptance Criteria

• Setting spec.hold: true on an AddonsLayer:
  • All owned HelmReleases get spec.suspend=true.
  • Each HR is annotated kraan/suspended-by-hold: "true".
  • A Normal event is recorded on the AddonsLayer summarizing how many were suspended.
• Removing hold:
  • Controller does not auto-unsuspend; on the next layer apply from Git, HelmReleases are updated with the repo spec (typically suspend: false) and Helm controller reconciles.
• Flux does not reconcile HRs due to ConfigMap/value changes while the layer is on hold.

Notes

• If an operator needs a specific HelmRelease to remain suspended after hold removal, keep spec.suspend: true in the repo manifest or re-apply it after the layer apply.