Add dependency_firewall_access feature flag and predicate

What does this MR do and why?

Adds a beta feature flag, dependency_firewall_access, and an Availability.access_enabled?(container) predicate that checks it. The flag is off by default.

New dependency firewall work, including work scoped to GA, needs one flag to be gated on. The existing flags (dependency_firewall_phase1, dependency_firewall_phase2, dependency_firewall_dashboard_v2 and dependency_firewall_group_prevented_stats) each cover one capability, and none of them separates GA scope from what beta customers already have. The team agreed on a single flag named after the feature, not a stage, and on gating new work behind it from now on.

The predicate follows the other flag predicates in Security::DependencyFirewall::Availability. It checks the flag against container&.root_ancestor, so enabling it for a top-level group covers the whole namespace.

Nothing calls the predicate yet. New work, starting with the package_version rule type under https://gitlab.com/groups/gitlab-org/-/work_items/22630, will gate itself on it as it lands.

This MR leaves the existing flags and predicates alone. Folding them into this flag is a follow-up: the existing flags are stubbed in 26 spec files (128 references), because flags are enabled by default in specs, so making the old predicates also honor the new flag changes what those specs see.

Why the flag is not called dependency_firewall

dependency_firewall would be the natural name, but a feature flag cannot share a name with a licensed feature, and dependency_firewall is one: it is in GitlabSubscriptions::Features::FEATURES_BY_PLAN, and Availability::FEATURE uses it for the license check.

• The feature flag docs say "You can't use a feature flag with the same name as a licensed feature name, because it would cause a naming collision", and recommend a dedicated flag under a different name.
• ee/spec/models/gitlab_subscriptions/features_spec.rb enforces it. I added a throwaway flag named dependency_firewall and ran that spec. It failed with Licensed feature 'dependency_firewall' has a matching feature flag. Please rename the feature or the FF.

A _ga suffix is out as well, because the naming guidelines say to avoid names that indicate the state or phase of a feature, such as _mvc, _alpha or _beta. That leaves a name that describes what the flag holds, which is access to the dependency firewall.

References

Resolves https://gitlab.com/gitlab-org/gitlab/-/work_items/633967

Part of https://gitlab.com/groups/gitlab-org/-/work_items/22126

The flag's rollout_issue_url points at the existing dependency firewall rollout issue, https://gitlab.com/gitlab-org/gitlab/-/work_items/591230.

Screenshots or screen recordings

Not applicable, there is no UI change.

How to set up and validate locally

1. In the Rails console, check the flag is off:

   group = Group.find_by_full_path('gitlab-org')
   Security::DependencyFirewall::Availability.access_enabled?(group) # => false

2. Enable it for that group and check again, including for a project inside it:

   Feature.enable(:dependency_firewall_access, group)
   Security::DependencyFirewall::Availability.access_enabled?(group) # => true
   Security::DependencyFirewall::Availability.access_enabled?(group.projects.first) # => true

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.