Revert "add var disable_hetzner_ccm"

[mysticaltech]

Reverts #1575

[mysticaltech]

Reverting PR #1575: Fixing Deployment Bug in Hetzner CCM

PR #1575 introduced the disable_hetzner_ccm variable, but it inadvertently caused a bug in the Hetzner Cloud Controller Manager (CCM) deployment. Here's why this PR is being reversed:

Original Design (Pre-PR #1575):

• The remote ccm-networks.yaml was included as a resource.
• The local ccm.yaml was used as a patch for customization.
• This pattern ensured flexibility while maintaining the correct kustomize structure.

Issue Introduced by PR #1575:

• Both ccm-networks.yaml and ccm.yaml are now included as resources.
• This creates a conflict, as both define the same Kubernetes resource: Deployment.v1.apps/hcloud-cloud-controller-manager in the kube-system namespace.
• The local ccm.yaml is still referenced as a patch, adding further confusion.

Why This is Problematic:

• Double Deployment: Two attempts to deploy the same resource.
• Broken Pattern: The kustomize resource/patch approach is disrupted.
• Increased Complexity: Configuration becomes harder to manage and error-prone.

While the intent to enable CCM disabling was valid, the implementation broke the existing kustomize pattern and introduced a conflict. This reversion restores the original structure, ensuring stability and clarity.

If CCM disabling is needed, it should be implemented while preserving the resource/patch pattern to avoid similar issues.

[pat-s]

@mysticaltech Just saw this now. Thanks for the extensive description.

The patch works for my use cases and adapting it to the structure of this module including the kustomize logic is probably not worth the effort. At least it would cost me a lot of time.

However, overall I'd argue that the option is pretty important as without this one cannot deploy HCCCM via helm (which is required when full compatibility is sought for robot servers). The helm variant does some magic behind the scenes which the kustomize one can't.