Reduce duplication in extension `ControlPlane` controllers by extracting reusable CSI components

[rfranzke]

/area control-plane
/kind enhancement
/label teamsize/medium

What is the topic about?:

Problem

Every provider extension (provider-aws, provider-gcp, provider-azure, provider-openstack, ...) implements its own ControlPlane controller that deploys largely identical components — most notably CSI drivers. Each provider reimplements:

• The full CSI controller Deployment spec (with generic sidecars like csi-provisioner, csi-attacher, csi-resizer, csi-snapshotter, csi-liveness-probe)
• The CSI node DaemonSet spec (with generic sidecars like csi-node-driver-registrar, csi-liveness-probe)
• Associated RBAC, PodDisruptionBudgets, monitoring/alerting configuration
• ManagedResource wiring for all of the above

The only truly provider-specific part is the driver container itself (image, args, volumes/mounts). Everything else is ~90% identical across providers but drifts over time. Bug fixes and CSI sidecar version bumps require N PRs across N providers.

Proposed Solution

Extract reusable CSI components into gardener/gardener core following the pattern established by pkg/component/nodemanagement/machinecontrollermanager/ — specifically its provider.go sidecar interface. The core provides the generic Deployment/DaemonSet structure, and extensions only supply the provider-specific driver container via a well-defined interface.

This means:

• Core manages: generic CSI sidecars, RBAC, PodDisruptionBudgets, monitoring, ManagedResource wiring
• Extensions provide: the driver container image, provider-specific args, volumes, and volume mounts

The same pattern could later extend to cloud-controller-manager (generic Deployment skeleton, provider-specific manager container), but CSI is the primary target.

Tasks

1. Audit current provider extensions: Compare ControlPlane controller implementations across providers (provider-aws, provider-gcp, provider-azure, provider-openstack) to catalog shared vs. provider-specific code. Quantify the duplication.
2. Design the reusable component: Define a core component in pkg/component/ with a provider interface (following the MCM sidecar pattern) for CSI controller and CSI node deployments.
3. PoC for one provider: Implement the new component and migrate one provider extension (e.g., provider-aws or provider-gcp) to validate the interface.
4. Evaluate cloud-controller-manager: Assess whether the same pattern applies to CCM and scope a follow-up if so.