Sync policies on policy configuration assign

What does this MR do and why?

Add the worker chain that processes PolicyConfigurationAssignedEvent to sync open merge requests across all projects under a configuration when a policy project is assigned.

Previously there was no mechanism to bulk-sync MR approval rules when a policy configuration was first assigned. This MR implements the fan-out chain: SyncPolicyConfigurationWorker → SyncPolicyConfigurationProjectWorker → LinkPolicyConfigurationService → SyncMergeRequestsForProjectWorker, all gated by the sync_policies_in_bulk_on_policy_configuration_assign flag introduced in the preceding MR.

SyncMergeRequestsService gains a policy_configuration_id: path so MRs can be synced for an entire configuration without iterating individual policies.

LinkPolicyConfigurationService and BasePolicyConfigurationService are extracted from the existing worker logic into proper service classes.

References

Issue: #600265

This MR is part of a series:

• Introduce PolicyConfigurationAssignedEvent and bulk sync flag (preceding MR)
• 👉 Sync policies on policy configuration assign (this MR)

How to set up and validate locally

1. Enable the feature flag:

   bin/rails runner "Feature.enable(:sync_policies_in_bulk_on_policy_configuration_assign)"

2. Create a group with at least two projects inside it (e.g. test-group with project-a and project-b).

3. In each project, create an open merge request targeting the default branch with a secret leak

env.sample

#AWS_TOKEN=AKIAZYONPI3G4JNCCWGX

4. Create a separate policy project — a plain project that will hold the security policies. Add the following files:

Test Setup

.gitlab/security-policies/policy.yml

approval_policy:
- name: Require approval on secrets
  description: ''
  enabled: true
  enforcement_type: enforce
  rules:
  - type: scan_finding
    scanners:
    - secret_detection
    vulnerabilities_allowed: 0
    severity_levels: []
    vulnerability_states: []
    branch_type: protected
  actions:
  - type: require_approval
    approvals_required: 1
    role_approvers:
    - owner
  - type: send_bot_message
    enabled: true
  approval_settings:
    block_branch_modification: false
    prevent_pushing_and_force_pushing: false
    prevent_approval_by_author: true
    prevent_approval_by_commit_author: false
    remove_approvals_with_new_commit: false
    require_password_to_approve: false
  fallback_behavior:
    fail: open

.gitlab-ci.yml

image: busybox:latest
include:
  - template: 'Jobs/Secret-Detection.gitlab-ci.yml'

5. Navigate to the group's Settings > Secure > Security policies.

6. Click Edit policy project and select the policy project created in step 4.

7. Navigate to the open MR in project-a and check the approval widget.

   Observation: The approval widget shows the policy "Require approval on secrets" requires 1 approval. The policy bot comment appears on the MR.

8. Navigate to the open MR in project-b and check the approval widget.

   Observation: Same policy approval requirement is reflected — both MRs are synced without having to push a new commit or manually trigger a sync.

9. To confirm the worker chain fired, check Sidekiq or the Rails log:

   grep "SyncPolicyConfigurationWorker\|SyncPolicyConfigurationProjectWorker\|SyncMergeRequestsForProjectWorker" log/sidekiq.log | tail -20

   Observation: All three worker classes appear in sequence.

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.