[app] Probes for the php-fpm container and startupProbes across workloads

[henzigo]

Context

• The php-fpm container has no probes at all — a wedged FPM master keeps receiving traffic
  until the nginx sidecar (which only checks its own /health stub) fails.
• All probes use initialDelaySeconds (30 s liveness delays) instead of startupProbe,
  which slows down rollouts and masks slow starts.

Proposal

1. Add probes to the php-fpm container: tcpSocket: 9000 as a minimum; ideally enable the FPM
   status page (pm.status_path = /status) in the shipped www.conf and probe it via
   cgi-fcgi/HTTP through nginx.
2. Introduce startupProbe for php-fpm, nginx, storefront and redis, and reduce
   initialDelaySeconds on liveness/readiness accordingly.
3. Expose all of it through the existing per-component probe values (already supported by the
   component schema).

Tasks

• php-fpm probes (+ optional FPM status page in www.conf)
• startupProbes for webserver/storefront/redis
• Unit tests for probe overrides, golden snapshot regeneration
• Validate rollout timing on a real cluster

[henzigo]

Concrete probe design already exists in two upstream PRs against the legacy package — port them
into this chart as part of this issue:

shopsys/deployment#71 (webserver):

• php-fpm pool config: enable ping.path = /ping + ping.response = pong in www.conf
• php-fpm container: tcpSocket probes on 9000 (liveness initialDelaySeconds: 30, periodSeconds: 10, timeoutSeconds: 2; readiness initialDelaySeconds: 2, periodSeconds: 5, timeoutSeconds: 2)
• nginx container: declare containerPort: 80 as named port health, probe /health via the
  named port with tuned thresholds (liveness periodSeconds: 10, timeoutSeconds: 3, failureThreshold: 6; readiness initialDelaySeconds: 2, periodSeconds: 5, timeoutSeconds: 2, failureThreshold: 3)
• default nginx vhost: /health proxies to the FPM /ping via fastcgi (with
  fastcgi_read_timeout 3s) instead of stub_status — nginx health then actually reflects FPM
  health (update charts/shopsys-app/files/nginx/project-nginx.conf)
• preStop normalization: ["/bin/sh","-lc","sleep 10; kill -QUIT 1 || true"]

shopsys/deployment#76 (storefront):

• startupProbe /api/health (periodSeconds: 2, timeoutSeconds: 2, failureThreshold: 60)
• liveness periodSeconds: 10, timeoutSeconds: 2, failureThreshold: 3 (no initialDelay)
• readiness periodSeconds: 3, timeoutSeconds: 2, failureThreshold: 1
• preStop ["/bin/sh","-lc","sleep 10"]

Coordination note: #2 (security contexts) wants the nginx health listener off port 80 — decide
the port there first, or land this with port 80 and move it in #2.

[henzigo]

Additional probe work to include in this issue's scope:

• cron container has no probes at all : add a startup + liveness probe checking the
  cron daemon is alive (pgrep -x crond || pgrep -x cron, or supercronic equivalent once [security] Run the cron container without root (supercronic) #3
  lands); readiness is unnecessary (not an LB target)
• php-fpm startupProbe : split startup (tcpSocket 9000, failureThreshold: 30 × periodSeconds: 5 = 150 s budget) from liveness so slow warmups don't get killed
• storefront thresholds (-7.5): soften the PR #76 values — readiness
  failureThreshold: 1 / periodSeconds: 3 causes Ready-flapping on transient hiccups; suggest
  failureThreshold: 2, periodSeconds: 5, timeoutSeconds: 3 and startup budget 200 s
• named ports in probes : use the named port (storefront) instead of numeric 3000
• redis health scripts : document the intentional liveness-vs-readiness LOADING
  asymmetry in the script comments; consider TCP liveness + exec readiness split