feat: implement rudimentary /v1/gitlab/bbm api for BBM controll

What does this MR do?

This MR implements the API endpoints for managing batched background migrations (BBMs) through the /v1/gitlab/bbm API. This enables chatops-based management of BBMs without requiring direct database access to production environments.

Implemented endpoints:

• GET /v1/gitlab/background-migrations/ - Retrieves the status of all background migrations
• GET /v1/gitlab/background-migrations/{bbmId}/ - Retrieves the status of a specific background migration by ID
• POST /v1/gitlab/background-migrations/pause/ - Pauses all eligible running/active background migrations
• POST /v1/gitlab/background-migrations/resume/ - Resumes all eligible paused background migrations

Implemented endpoints:

• GET /v1/gitlab/bbm/status/ - Retrieves the status of all background migrations
• POST /v1/gitlab/bbm/pause/ - Pauses all eligible running/active background migrations
• POST /v1/gitlab/bbm/resume/ - Resumes all eligible paused background migrations

Note: The synchronous running of BBMs (equivalent of running cli command background-migrate run ...) not yet implemented as its long-running nature does not fit into HTTP REST API.

Key changes:

1. New API routes (registry/api/gitlab/v1/routes.go):
   • Added background migrations base route and sub-routes for status (all and by ID), pause, and resume operations
   • Registered routes in the router with proper path hierarchy
2. Handler implementation (registry/handlers/background_migrations.go):
   • Created backgroundMigrationsHandler with methods for each endpoint
   • Implemented JSON response structures for migrations list and action responses
   • Integrated with existing bbm.Worker for database operations
3. Authorization and routing (registry/handlers/app.go):
   • Added BBM access control with read/write permissions based on endpoint type
   • Exempted BBM routes from repository name requirement
   • Registered dispatchers for status, pause, and resume endpoints

Authentication:

• Status endpoint requires read access to registry:background-migrations resource
• Pause/resume endpoints require write access to registry:background-migrations resource

Related to #1774 (closed)

Author checklist

• Assign one of conventional-commit prefixes to the MR.
  • fix: Indicates a bug fix, triggers a patch release.
  • feat: Signals the introduction of a new feature, triggers a minor release.
  • perf: Focuses on performance improvements that don't introduce new features or fix bugs, triggers a patch release.
  • docs: Updates or changes to documentation. Does not trigger a release.
  • style: Changes that do not affect the code's functionality. Does not trigger a release.
  • refactor: Modifications to the code that do not fix bugs or add features but improve code structure or readability. Does not trigger a release.
  • test: Changes related to adding or modifying tests. Does not trigger a release.
  • chore: Routine tasks that don't affect the application, such as updating build processes, package manager configs, etc. Does not trigger a release.
  • build: Changes that affect the build system or external dependencies. May trigger a release.
  • ci: Modifications to continuous integration configuration files and scripts. Does not trigger a release.
  • revert: Reverts a previous commit. It could result in a patch, minor, or major release.
• MR contains database changes including schema/background migrations:
  • Do not include code that depends on the schema migrations in the same commit. Split the MR into two or more.
  • Do not include code that depends on background migrations in the same release.
  • Manually run up and down migrations in a postgres.ai production database clone and add a link for the query plan(s) to the MR.
  • If adding new schema migrations make sure the REGISTRY_SELF_MANAGED_RELEASE_VERSION CI variable in migrate.yml is pointing to the latest GitLab self-managed released registry version. Find the correct registry version here. Make sure to select the branch of the latest GitLab release.
  • If adding new queries, extract a query plan from postgres.ai and post the link here. If changing existing queries, also extract a query plan for the current version for comparison.
    • I do not have access to postgres.ai and have made a comment on this MR asking for these to be run on my behalf.
  • If adding new background migration, follow the guide for performance testing new background migrations and add a report/summary to the MR with your analysis.
• Change contains a breaking change - apply the breaking change label.
• Change is considered high risk - apply the label high-risk-change
• I created or linked to an existing issue for every added or updated TODO, BUG, FIXME or OPTIMIZE prefixed comment
• Changes cannot be rolled back
  • Apply the label cannot-rollback.
  • Add a section to the MR description that includes the following details:
    • The reasoning behind why a release containing the presented MR can not be rolled back (e.g. schema migrations or changes to the FS structure)
    • Detailed steps to revert/disable a feature introduced by the same change where a migration cannot be rolled back. (note: ideally MRs containing schema migrations should not contain feature changes.)
    • Ensure this MR does not add code that depends on these changes that cannot be rolled back.

Documentation/resources

Code review guidelines

Go Style guidelines

Feature flags

When documentation is required

Documentation workflow

Reviewer checklist

• Ensure the commit and MR tittle are still accurate.
• If the change contains a breaking change, verify the breaking change label.
• If the change is considered high risk, verify the label high-risk-change
• Identify if the change can be rolled back safely. (note: all other reasons for not being able to rollback will be sufficiently captured by major version changes).