Replace usage of Helm release revision with a stable hash in Job names

What does this MR do?

Originally jobs in GitLab were suffixed with the Helm .Release.Revision which was not ideal because it would always cause an update of the job when running helm upgrade --install, even if nothing has changed. And it also prevented the proper work with workflows that are based on helm template for example when using ArgoCD. The decision to use the .Release.Revision in the name was based on the preconditions that the job might only be executed once and that helm uninstall wouldn't delete jobs, which are (now) wrong.

Now, job names by default are suffixed with a hash that is based on the chart's app version and the chart's values, which also might contain the global.gitlabVersion. This approach ensures job names remain stable across multiple helm template and helm upgrade --install executions (if nothing changed), and it's even possible to modify values of immutable fields of the job without errors during deployments (the jobs are just replaced with new ones due to the new names).

It is possible to override the hash that gets generared by default with a custom suffix by setting global.job.nameSuffixOverride. The field supports templating, so it is possible to reproduce the old behavior of using the .Release.Revision as a name suffix:

global:
  job:
    nameSuffixOverride: '{{ .Release.Revision }}'

If you intentionally always want to trigger a change, for example because you are working with floating tags such as latest for all your versions, you can override the hash that gets generated by default with a dynamic value such as a timestamp:

global:
  job:
    nameSuffixOverride: '{{ dateInZone "2006-01-02-15-04-05" (now) "UTC" }}'

Alternatively, you can use it with helm in the command line:

helm <command> <options> --set global.job.nameSuffixOverride=$(date +%Y-%m-%d-%H-%M-%S)

Related issues

Closes #734 (closed)

Closes #3021 (closed)

Closes #3832 (closed)

Related to !2863 (closed)

Related to !3528 (closed)

Author checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

• Merge Request Title and Description are up to date, accurate, and descriptive
• MR targeting the appropriate branch
• MR has a green pipeline on GitLab.com (https://gitlab.com/gitlab-org/charts/gitlab/-/pipelines/1218352969)
• When ready for review, follow the instructions in the "Reviewer Roulette" section of the Danger Bot MR comment, as per the Distribution experimental MR workflow

For merge requests from forks, consider the following options for Danger to work properly:

• Consider using our community forks instead of forking your own project. These community forks have the GitLab API token preconfigured.
• Alternatively, see our documentation on configuring Danger for personal forks.

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes (!3602 (comment 1778303818))
• Documentation created/updated
• Tests added/updated
• Integration tests added to GitLab QA
• Equivalent MR/issue for omnibus-gitlab opened~~ I guess not needed?
• Equivalent MR/issue for Gitlab Operator project opened (see Operator documentation on impact of Charts changes) -> gitlab-org/cloud-native/gitlab-operator#1530 (closed)
• Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme://user:passwd@host:port may require quotation or other special handling when rendered in a template and written to a configuration file.

Test plan

!3602 (comment 1778303818):

This is tested by manually tweaking version and appVersion in Chart.yaml on a local copy and using helm template --set ... test . | yq 'select(.kind == "Job") | .metadata.name' to verify different scenarios.