config: Fix readiness probe causing ~3m startup delay (#610)

PR #555 changed readiness probe periodSeconds from 10 to 180 to
anticipate big clusters with 10K VMs. However, periodSeconds controls
how often Kubernetes checks the probe, not how long to tolerate
initialization. With periodSeconds=180, if the first probe at T=10s
fails (e.g. webhook server not yet serving), the next attempt is at
T=190s, leaving the pod not-Ready for over 3 minutes.

Restore periodSeconds to 10s. The pool manager's /readyz endpoint
already handles long initialization correctly — it returns failure
until IsReady() is true, and Kubernetes keeps probing every
periodSeconds until it succeeds.

Assisted-by: Claude Opus 4.6 <noreply@anthropic.com>

Signed-off-by: Ram Lavi <ralavi@redhat.com>

Author: RamLavi

config/default/manager/manager.yaml

@@ -136,7 +136,7 @@ spec:
             port: webhook-server
             scheme: HTTPS
           initialDelaySeconds: 10
-          periodSeconds: 180
+          periodSeconds: 10
         livenessProbe:
           httpGet:
             httpHeaders:

config/release/kubemacpool.yaml

@@ -329,7 +329,7 @@ spec:
             port: webhook-server
             scheme: HTTPS
           initialDelaySeconds: 10
-          periodSeconds: 180
+          periodSeconds: 10
         resources:
           requests:
             cpu: 100m

config/test/kubemacpool.yaml

@@ -330,7 +330,7 @@ spec:
             port: webhook-server
             scheme: HTTPS
           initialDelaySeconds: 10
-          periodSeconds: 180
+          periodSeconds: 10
         resources:
           requests:
             cpu: 100m