CI: Make `master`/`stable` pipeline Review Apps consistent with merge request pipelines

What does this MR do?

Implements the changes discussed in #5347 (closed).

Related issues

Closes #5347 (closed)

Closes #5334 (closed)

Closes #5296 (closed)

Closes #5287 (closed)

Impacts

For developers

• Feel more comfortable pushing multiple commits in close succession without worrying about overloading CI or causing conflicts in the Review App environments
• Worry less about pushing docs-only changes when the branch naming rule hasn't been followed
• Have more confidence in the changeset knowing tests that the same tests that passed in your MR pipeline will run in the master/stable pipelines

General

• No more long-lived production environments
• Environments for Merge Request, stable, and master pipelines are isolated per-commit
• Environments for Merge Request, stable, and master pipelines are shortened from 2 days to 2 hours
• We no longer need resource_groups to prevent multiple pipelines from affecting the same environment
• stop_review jobs first try to check out the current branch instead of always checking out master first

To do after merge

CI: Clean up resources related to "production" ... (#5370 - closed)

Test plan

🚧 In progress

While we can't fully test this until we've merged to master/stable, we should be 'safer' than usual now that these jobs are used the same way there as they are in this MR's CI.

• Pipeline editor: Visualize looks correct
• Pipeline editor: Validate passes

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
• 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
• Documentation created/updated
• Tests added/updated
• Integration tests added to GitLab QA
• Equivalent MR/issue for omnibus-gitlab opened
• Equivalent MR/issue for Gitlab Operator project opened (see Operator documentation on impact of Charts changes)
• 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.