Separate Release environment creation from tagging

Context

A new Release environment (RE) is created when a monthly version is released. It is currently done by having the Rake task doing it at the end of the tagging task (code). Logically, it is correct. However, if for whatever reason, the RE creation fails, we have to retry the whole tagging job. Its consequences:

• First of all, retrying the whole tagging job doesn't change the result of the job (i.e. no bad consequence), since the release tasks are immutable
• However, it wastes time and computing power, since tagging tasks were already done
• And it may make a false impression/understanding, looking at the release pipeline, that the tagging action fails

Proposal

Move the rake task creating the new RE to a new job. This logic is aligned with the work to create the early branch one week early gitlab-com/gl-infra/software-delivery&1 (closed). #21101 (closed) introduced CI configuration to automate the creation of a release candidate. A new job can be added to create the release environments

Exit Criteria

• Add a new job to the initial_rc stage: monthly_release:initial_rc:release_environment. This job should depend on the successful execution of the initial_rc:tag job
• Trigger the creation of a release environment on the new job.
• A notification should be sent to Slack about the status of the job. Similar to
• Modifications to the tag task should be under a feature flag: If the feature flag is enabled the creation of the RE should be skipped, if the feature flag is disabled the creation of the RE should still be part of the tag task.