Migrations: Base job name on version and values hash, allow setting job's TTL

What does this MR do?

The former job name was based on the Helm .Release.Revision which is considered bad practice because it will always cause an update of the job when running helm upgrade --install even though nothing changed. And it also prevents the proper work with workflows that are based on helm template e.g. 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.

Starting with this change, the job name is 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 way the job name gets a name that is stable amongst helm template and multiple helm upgrade --install (if nothing changed), and it's even possible to modify values of immutable fields of the job without errors during deployments (as the job will just be replaced due to the new name).

Also allow setting job's ttlSecondsAfterFinished (other commit)

Related issues

Related to #734 (closed)

Related to #3021 (closed)

Relatead to #3832 (closed)

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
• When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes
• Documentation created/updated
• Tests added
• Integration tests added to GitLab QA
• Equivalent MR/issue for omnibus-gitlab opened
• 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.