Draft: Add Search::Scopes registry to centralize scope definitions
What does this MR do and why?
This change refactors how search functionality is organized in GitLab by creating a centralized system for managing different search categories (called "scopes").
Previously, each search service had its own hardcoded list of what could be searched (like projects, issues, code, etc.). Now there's a single registry that defines all available search categories, their labels, where they can be used, and what search technologies they work with.
The main benefits are:
- Centralized management: All search categories are now defined in one place instead of scattered across multiple files
- Automatic feature detection: The system can automatically determine what search features are available (basic search, advanced search with Elasticsearch, or Zoekt code search)
- Better organization: Search categories are properly sorted and consistently labeled across the application
- Easier maintenance: Adding new search categories or modifying existing ones only requires changes in the central registry
The change also improves how GitLab's Enterprise Edition features (like searching for "Epics") are integrated, making the code more modular and easier to extend. The navigation menus and search interfaces now automatically adapt based on what search capabilities are enabled in the system.
References
Screenshots or screen recordings
| Before | After |
|---|---|
How to set up and validate locally
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.
Related to #567844