Signed-off-by: Max Gautier <[email protected]>

Referencing the secrets in the `secrets` fields of the ServiceAccount
will make kubernetes consider it an auto-generated secret, and:
1. Warn about its usage in API responses
2. Subject it to automatic cleanup after roughly one year if unused

See:
- https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#legacy-serviceaccount-token-cleaner
- https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#create-token

Signed-off-by: Max Gautier <[email protected]>

Kubernetes legacy ServiceAccount tokens will generate warnings on use
and be garbage collected if not used for one year, starting with
Kubernetes 1.30.

Use an explicitly created token secret with a fixed name, based on the
service account name.

Signed-off-by: Max Gautier <[email protected]>

This align clusterauth_test with the expected behavior modified by the
previous commit, and is more in line with the way Kubernetes service
account secrets are handled by the token controller.

Signed-off-by: Max Gautier <[email protected]>

Test all 3 cases:
- token secret already exists -> we should not create another
- token secret does not exists
- error on secret creation.

Since getOrCreateServiceAccountSecretToken does not actually look at the
content of the token itself, we remove the part of the test related to
this.

Signed-off-by: Max Gautier <[email protected]>