Add feature flag for a phased rollout of cleanup policies

🎉 🎊 MR 44444! Woohoo! 🎉 🎊

🌲 Context

The container registry is a place to host Docker images and their related tags. With time, images can accumulate a fair share of tags. These tags takes a non trivial amount of filesystem space on the container registry.

To address this, we introduced container cleanup policies in 12.8. Policies will run on a recurrent schedule and deletes the old tags that their parameters target.

This policy execution is a heavy background process and we didn't let all projects have cleanup policies on gitlab.com: projects before 12.8 can't have a cleanup policy. To accommodate self-managed needs, an application setting has been introduced that allows all projects to have a policy. This application setting is currently disabled on gitlab.com for scalability reasons.

🤔 What does this MR do?

With #208193 (closed), we're tackling the scalability issue of this heavy background process. This MR addresses #244050 (closed): a way to slowly include the pre 12.8 projects. In short, we want a way to mark pre 12.8 project so that they can have a cleanup policy too.

The easiest way is to introduce a new feature flag that is scoped by projects. This feature flag will override the application setting (the one discussed in the context) and let the project have a cleanup policy.

⚔ Design choices

• The cleanup policy form is controlled by a property sent to the Vue component
• This MR creates a new helper to compute the value (true or false) for this property:
  • We either have the application setting enabled or the project has the new project scoped feature flag enabled.
• Please note that enabling the feature flag will not automatically create the cleanup policy for the project. It will merely allow the cleanup policy form to be displayed in the UI and users will be able to save it = a new cleanup policy object will be created.
• Update the helper specs
• Update the feature tests:
  • While at it, improve them by:
    • Using let_it_be vars to 🚀 execution time.
    • Use subject instead of the same before block everywhere
  • Use a table spec for our feature spec to check all the possible combinations between the application setting and the feature flag
• feature flag tracking issue: https://gitlab.com/gitlab-org/gitlab/-/issues/262639

📸 Screenshots

Given a project that doesn't have a cleanup policy (that's the state of pre 12.8 projects).

Here is the cleanup policy form (in *project_path*/-/settings/ci_cd):

With the ⛳ feature flag disabled

With the ⛳ feature flag enabled

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team