Periodic Drift Detection and Resync

[lukidoescode]

Motivation

The operator uses push-on-CRD-change semantics — it only reconciles when a CRD's spec changes. If someone manually modifies lldap state (via web UI or direct API), the operator will never detect the drift until the CRD is next modified. Periodic resync catches drift and restores the declared state.

Definition of Done

• All four reconcilers support a configurable resync interval (Helm value resync.interval, default 5m). The interval is applied as a periodic requeue via Action::requeue(interval) after successful reconciliation, replacing Action::await_change() from Ticket Reconciliation Robustness and Startup Behavior #15.
• On each resync, the reconciler queries lldap for the current state of the managed resource and compares it against the CRD spec.
• If drift is detected: the reconciler corrects it by pushing the CRD's desired state to lldap and emits a Warning/DriftCorrected Kubernetes event with details of what changed.
• Password policy is respected during resync:
  • Manage: password hash is compared and corrected if changed.
  • InitialOnly: password is NEVER re-applied during resync. Only non-password fields are compared and corrected.
  • Ignore: password is skipped entirely during resync. Only non-password fields are compared and corrected.
• A Prometheus metric lldap_operator_drift_corrections_total{resource} tracks how often drift is detected.
• Resync does not generate spurious updates: if the lldap state already matches the CRD spec, no API call is made and no event is emitted.
• Documentation: Document the resync behavior in the Configuration Reference (interval setting) and Troubleshooting chapter (what drift correction events mean). Document password policy interaction.

Technical Details

• The resync interval replaces Action::await_change(). After a successful reconcile, return Action::requeue(Duration::from_secs(interval)).
• On resync, the reconciler always queries lldap for current state (unlike the normal path which uses status as a cache). This ensures actual drift is detected, not just status staleness.
• lldap has no change subscription/webhook API — periodic polling is the only option for drift detection.
• Consider making the interval per-CRD-type if some resources are more sensitive than others (e.g., users vs. attribute schemas). For now, a single global interval is sufficient.
• The resync requeue timer resets on every reconcile (spec change or periodic). This means a frequently-modified CRD won't pile up resyncs.