feat: make the probe timings configurable

[andreidorin-oprea]

What this PR does

Exposes the liveness, readiness and startup probe timings as Helm values. The defaults are exactly what the chart applies today, so this is a no-op unless you set them.

probes:
  startup:
    periodSeconds: 10
    failureThreshold: 12
    timeoutSeconds: 1
  liveness:
    periodSeconds: 10
    failureThreshold: 3
    timeoutSeconds: 1
  readiness:
    periodSeconds: 10
    failureThreshold: 3
    timeoutSeconds: 1

Paths and ports stay fixed - they have never been the thing people needed to change.

Why

The probes have been retuned in place three times, each time to suit whichever cluster the reporter had:

PR	change	reason
#2254	added the liveness probe	-
#2844	raised initialDelaySeconds	"operator pod was running into timeouts on my arm64 mac machine ... so operator gets more time to load and apply CRDs"
#4791	replaced it with a startup probe at 10s x 12	that delay now penalised fast startups: "ASO finish starting up after about 10s, then idle for an extra ~45s"

#2844 made startup too slow for small clusters, and #4791 made it too tight for large ones. We are at the far end of that range: the operator applies its CRDs and starts a controller per installed CRD before it serves /healthz, and on our production cluster - roughly 800 CRDs - that outlasts the 120s budget, so the kubelet kills it mid-apply and it never finishes starting.

Our only workaround today is a Helm post-renderer that rewrites the probe after the chart has rendered, which breaks silently whenever the chart's deployment changes shape.

Rather than move the constant a fourth time and push the problem back to the small-cluster end, this makes it a knob. Raising failureThreshold costs nothing on a fast startup, because a startup probe stops as soon as it first succeeds.

Special notes

• v2/config/manager/manager.yaml gets the same three fields on each probe so controller:validate-helm keeps matching the chart against the kustomize output.
• The only difference in the rendered output with default values is that the Kubernetes defaults for the liveness and readiness probes (periodSeconds: 10, failureThreshold: 3, timeoutSeconds: 1) are now written out explicitly instead of being implied. Behaviour is unchanged.
• I deliberately left successThreshold out. Kubernetes requires it to be 1 for liveness and startup probes, so exposing it would mostly be a way to write an invalid config.
• There is a small textual overlap with feat: make the leader election lease timings configurable #5707 in diagnosing-problems/_index.md; both add a section under Common mistakes. Whichever lands second is a trivial rebase.

How does this PR make you feel?

Checklist

• this PR contains documentation

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Note

This error may be related to your runner configuration. You can now configure runners for Copilot code review separately from Copilot cloud agent by creating a copilot-code-review.yml file with your setup steps. Read the docs for details.

[Matthew Christopher (matthchr)]

LGTM, small doc nit.

[Bevan Arps (theunrepentantgeek)]

Looks good; will be happy to merge once the docs are tweaked.

[andreidorin-oprea]

Bevan Arps (@theunrepentantgeek) docs tweaked in ea7e840 - Matthew Christopher (@matthchr)'s suggestion applied verbatim, comment-only change. Ready for merge.