Add MR-level approval rules version flag and update services to use it

Add migration-safe mechanism for supporting both v1 and v2 approval rules simultaneously during transition.

What

  1. Database migration: Add approval_rules_version column to merge_requests table (enum: v1, v2; default: v1)
  2. Create service: When FF is enabled, set new MRs to approval_rules_version = 'v2'
  3. Update service: Check MR's approval_rules_version flag instead of FF
    • v1 MRs → use v1 approval rules logic
    • v2 MRs → use v2 approval rules logic
  4. Individual rule services (Create, Update, Destroy): Check MR's version flag to determine which rules table to operate on
  5. Tests: Verify both v1 and v2 MRs work correctly

Why

Enables safe rollout where:

  • Existing v1 MRs continue to work unchanged
  • New v2 MRs use the new system
  • Both versions coexist during migration period

Migration Strategy

  • Phase 1: Add flag, update services to use it (this issue)
  • Phase 2: Enable FF in production (new MRs use v2)
  • Phase 3: Backfill existing MRs to v2 (separate issue)
  • Phase 4: Remove v1 code (after backfill complete)
Edited by 🤖 GitLab Bot 🤖