Throttle auto-remediation scheduler runs per project

What does this MR do and why?

Limits auto-remediation to one scheduler run per project every five minutes, behind the dependency_management_scheduler_rate_limit flag. One project's SBOM ingestions could start the scheduler dozens of times an hour, and each run schedules workloads on shared runners. This is Phase 1 of Project Bulkhead for Code Security.

• SchedulerService#execute checks the limit after the profile check. A throttled run logs DependencyManagement: scheduler run throttled and returns. GitLab does not retry it, and the project's next SBOM ingestion starts a fresh run.
• Reschedules use their own key with the same limit. A reschedule is queued from inside an admitted run's window, so on a shared key it would always be dropped.
• Feature branch and registry image scan pipelines stop starting runs in !268981 (merged). It must be deployed before this flag is enabled, so those runs cannot take the default branch's window.
• Open remediation MRs are counted only after the limit check, so a throttled run or a project without a profile no longer queries them.

The five-minute period is a constant while the flag is the safety switch. The MR that removes the flag adds an application setting to change or disable the limit.

A run that raises part way through still uses up its window, so a Sidekiq retry within five minutes is throttled and the job finishes as a success. The next ingestion after the window starts a fresh run.

A reschedule queued by a reschedule run's own workload usually lands in the same window and is dropped. That caps reschedule chains, and the freed slot waits for the next ingestion.

No changelog entry while the flag is disabled by default.

References

• Issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/636846
• Epic: https://gitlab.com/groups/gitlab-org/-/work_items/24282
• Permission skip that goes ahead of the limit when it lands: !266638 (merged)
• Default branch trigger filter, deployed before this flag is enabled: !268981 (merged)

Screenshots or screen recordings

Not applicable, no UI changes.

How to set up and validate locally

1. Pick a project with a dependency scanning auto-remediation profile attached, and enable the flag in the Rails console:

   Feature.enable(:dependency_management_scheduler_rate_limit)
   project = Project.find(<project_id>)

2. Run the scheduler twice within five minutes:

   2.times { DependencyManagement::SecurityUpdate::SchedulerService.execute(project: project) }

   log/application_json.log has one DependencyManagement: scheduler run throttled line with "rate_limit_key":"dependency_management_scheduler_run".

3. Run a reschedule in the same window:

   DependencyManagement::SecurityUpdate::SchedulerService.execute(project: project, skip_dismissed_branches: true)

   No new throttle line, because reschedules have their own key. A second reschedule logs "rate_limit_key":"dependency_management_scheduler_reschedule".

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.