Add configurable revisionHistoryLimit to Druid node spec

[aruraghuwanshi]

Expose an optional revisionHistoryLimit on the Druid node spec and wire it into both the generated Deployment and StatefulSet. When unset, the Kubernetes default of 10 is preserved, so the change is non-breaking.

Bounding the retained history lets Kubernetes garbage-collect superseded ReplicaSets (Deployment node types) and ControllerRevisions (StatefulSet node types) that otherwise keep pod-template references to old container image tags. For Deployment node types in particular, those superseded scaled-to-zero ReplicaSets are first-class workload objects, so the old tags they pin can show up in container image inventories and security scanners as "in use" even though nothing is running them.

Description

Problem. By default Kubernetes retains up to 10 superseded, scaled-to-zero ReplicaSets (Deployment node types) / ControllerRevisions (StatefulSet node types) per workload. Each one keeps a pod-template reference to an old container image tag, so those tags keep showing up in image inventories and scanners long after the workload has moved on and is no longer running — inflating "in-use image" counts with versions that aren't actually running anywhere.

Solution. Add an optional revisionHistoryLimit (*int32) to the Druid node spec and pass it through to the generated workload's spec.revisionHistoryLimit. Because it is a pointer with omitempty, leaving it unset yields nil, which preserves the Kubernetes default (10) — fully backward-compatible and opt-in per node type.

Behavior.

• Deployment node types (e.g. routers): caps the retained ReplicaSets.
• StatefulSet node types: caps the retained ControllerRevisions.
• Unset → nil → Kubernetes default (10) → no change for existing clusters.
• revisionHistoryLimit is a freely-mutable field on both Deployments and StatefulSets and is not part of the pod template, so setting or changing it does not by itself trigger a pod rollout — Kubernetes just garbage-collects the excess history.

Validation. Verified end-to-end on a local kind cluster (Kubernetes v1.35) by building this change and exercising a router node configured as a Deployment:

• Configurable / CR-driven — setting revisionHistoryLimit: 4 on the node spec propagated to the generated Deployment (spec.revisionHistoryLimit: 4) within ~3s; the value is stored on the CR (not pruned by the CRD).
• Backward-compatible — with the field unset, the generated Deployment showed the Kubernetes default of 10.
• History is bounded — rolling the router repeatedly capped the retained ReplicaSets at the configured limit (1 active + 4 retained = 5) instead of climbing toward 10.
• Unit tests cover set / unset on both Deployment and StatefulSet node types.
• Full write-up with terminal evidence: https://aruraghuwanshi.github.io/druid-operator/revisionhistorylimit-e2e.html

---

This PR has:

• been tested on a real K8S cluster to ensure creation of a brand new Druid cluster works.
• been tested for backward compatibility on a real K8S cluster by applying the changes introduced here on an existing Druid cluster. If there are any backward incompatible changes then they have been noted in the PR description.
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added documentation for new or modified features or behaviors.

---

Key changed/added files in this PR

• apis/druid/v1alpha1/druid_types.go — add optional RevisionHistoryLimit *int32 to the node spec
• controllers/druid/handler.go — pass the value through in makeDeploymentSpec and makeStatefulSetSpec
• controllers/druid/handler_test.go — unit tests (set on a Deployment/StatefulSet node → generated object carries the value; unset → nil)
• examples/tiny-cluster.yaml — example usage + comment clarifying ReplicaSets (Deployment) vs ControllerRevisions (StatefulSet)
• apis/druid/v1alpha1/zz_generated.deepcopy.go, config/crd/bases/druid.apache.org_druids.yaml, chart/crds/druid.apache.org_druids.yaml — generated (deepcopy + CRDs)

[aruraghuwanshi]

nudge on the workflow-approval @AdheipSingh when you get a chance. Thank you!