fix(seaweedfs): fix s3 probe scheme and cosi ServiceAccount naming broken by 4.31 - #2904

…s Deployment

The cosi objectstorage-provisioner Deployment requests serviceAccountName via the
seaweedfs.componentName helper (release-name derived, e.g.
seaweedfs-system-objectstorage-provisioner), but the ServiceAccount and the
ClusterRoleBinding subject were named from
{{ .Values.global.seaweedfs.serviceAccountName }}-objectstorage-provisioner. With
cozystack's global.seaweedfs.serviceAccountName ("tenant-foo-seaweedfs") differing
from the release name, the SA is created under a name the Deployment never
references, so the ReplicaSet cannot create pods:

  serviceaccount "seaweedfs-system-objectstorage-provisioner" not found

and the provisioner never starts, leaving the seaweedfs-system HelmRelease stuck.

Name the SA and the RoleBinding subject with the same componentName helper the
Deployment uses, so all three always agree regardless of the configured
serviceAccountName. Carried as patches/cosi-sa-componentname.patch so it survives
`make update` re-vendoring; this should also be sent upstream to
seaweedfs/seaweedfs-helm (the bug is latent there, hidden only when
serviceAccountName == fullname).

Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>

Add two helm-unittest suites guarding the install-blocking regressions:

- cosi_serviceaccount_test.yaml: with global.seaweedfs.serviceAccountName set to
  a value other than the release name, asserts the cosi ServiceAccount, the
  ClusterRoleBinding subject, and the Deployment serviceAccountName all resolve
  to the same componentName-derived name. Mutation-verified: restoring the
  serviceAccountName-based SA name fails the suite.

- s3_probe_scheme_test.yaml: asserts the s3 readiness/liveness probes use scheme
  HTTP, matching the plain-HTTP s3 port.

Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>

The 'Configure Tenant and wait for applications' test waited 10m for
hr/etcd hr/ingress hr/monitoring hr/seaweedfs hr/tenant-root, but
seaweedfs installs as a serial chain seaweedfs-db (CNPG bootstrap,
HR timeout 10m) -> seaweedfs-system (HR timeout 10m) -> seaweedfs
wrapper. On a loaded CI runner each stage can run close to its own
HR timeout, so a 10m wait is smaller than the chain it waits on and
times out with the chain still converging (observed in runs
27293490370, 27293636512, 27331238229: master/filer/volume Running,
s3 pods 2-4m old still settling, seaweedfs-db remediated mid-flight).
20m covers the serial worst case while a real regression still fails
deterministically.

Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>

… chain

The tenant-root/seaweedfs umbrella HelmRelease had timeout: 10m, but its
helm action waits for the serial child chain seaweedfs-db (CNPG bootstrap,
own HR timeout 10m) -> seaweedfs-system (own HR timeout 10m). The umbrella
timeout was therefore structurally smaller than its children's legitimate
worst case. On a loaded cluster the umbrella hit 10m mid-convergence, and
because install/upgrade remediation is retries: -1, uninstall remediation
then deleted both child HRs -- including the half-bootstrapped seaweedfs-db
database -- and reinstalled from zero, looping forever (observed in e2e
runs 27293490370, 27293636512, 27331238229: UninstallSucceeded on
seaweedfs-db, seaweedfs-db-1 Terminating, fresh s3 pods every cycle).

Raising the umbrella timeout to 20m covers the serial child chain. This is
a failure backstop, not a fixed wait: Ready still flips the moment the
chain converges. It also removes a destructive reset that would delete a
tenant's seaweedfs database mid-bootstrap on any slow real-world cluster,
not just in CI.

Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>