docs: Update migration handling for next version

[aarnq]

Warning

This is a public repository, ensure not to disclose:

• personal data beyond what is necessary for interacting with this pull request, nor
• business confidential information, such as customer names.

What kind of PR is this?

Required: Mark one of the following that is applicable:

• kind/feature
• kind/improvement
• kind/deprecation
• kind/documentation
• kind/clean-up
• kind/bug
• kind/other

Optional: Mark one or more of the following that are applicable:

Important

Breaking changes should be marked kind/admin-change or kind/dev-change depending on type
Critical security fixes should be marked with kind/security

• kind/admin-change
• kind/dev-change
• kind/security
• kind/adr

What does this PR do / why do we need this PR?

This implements the idea of change for migrations that was proposed before to combat the divergence around releases, and to simplify contribution.
The idea is that the migration/main is the one under development, and during release it is promoted to the release series, example migration/v0.44.

Hopefully this change in process will also be helpful to realise #2287, with reusable snippets naturally as we go.

This is in a POC phase, as I've implemented the change in migration structure, but yet to implement the handling in the bin scripts, as I want it to be finalised first.
The process documents supporting migration contribution and release will also need more updates once completed.

Information to reviewers

./migration/promote.sh v0.44
It is also re-runnable.

Checklist

• Proper commit message prefix on all commits
• Change checks:
  • The change is transparent
  • The change is disruptive
  • The change requires no migration steps
  • The change requires migration steps
  • The change upgrades CRDs
  • The change updates the config and the schema
• Documentation checks:
  • The public documentation required no updates
  • The public documentation required an update - [link to change](set-me)
• Metrics checks:
  • The metrics are still exposed and present in Grafana after the change
  • The metrics names didn't change (Grafana dashboards and Prometheus alerts are not affected)
  • The metrics names did change (Grafana dashboards and Prometheus alerts were fixed)
• Logs checks:
  • The logs do not show any errors after the change
• Pod Security Policy checks:
  • Any changed pod is covered by Pod Security Admission
  • Any changed pod is covered by Gatekeeper Pod Security Policies
  • The change does not cause any pods to be blocked by Pod Security Admission or Policies
• Network Policy checks:
  • Any changed pod is covered by Network Policies
  • The change does not cause any dropped packets in the NetworkPolicy Dashboard
• Audit checks:
  • The change does not cause any unnecessary Kubernetes audit events
  • The change requires changes to Kubernetes audit policy
• Falco checks:
  • The change does not cause any alerts to be generated by Falco
• Bug checks:
  • The bug fix is covered by regression tests

[aarnq]

Note to self: Update public docs maintenance page.

[anders-elastisys]

Great work, really good that this is getting finally getting addressed as I know that the old system could be problematic if migrations steps did not end up in the proper release folder before a release was in progress. Left some comments, but overall I think it looks really good, have not tested the scripts yet however

[anders-elastisys]

Maybe expand this part a bit.

Suggested change

	For prepare the init step is given.
	For the prepare part, a init step is always included in each migration which runs the `ck8s init` command.

[aarnq]

I'm not sure how to rewrite it, because the hope is that we will have more and more persistent migration snippets, so it wont just be init and apply.
I want to remove it, or maybe just state that one should look for the current ones, and give init and apply as examples as a prepare and apply snippet respectively.
🤔

[anders-elastisys]

Maybe have a link to the respective folders and then provide the init and apply snippets as examples, but I would not say this is blocking in any way