Zoekt search support custom role with read_code ability

What does this MR do and why?

This MR introduces traversal_ids support in exact code search for:

• access at group or project with a custom role of GUEST access + read_code role. This enables users to see code in PRIVATE groups and projects with GUEST role.

AI Summary

This code change adds support for custom roles in the search functionality. Previously, users could only search through projects and groups based on standard permission levels (like Guest, Reporter, etc.). Now, the system can also check if users have custom roles with specific abilities (like "read_code") that grant them access to search through repositories they wouldn't normally be able to access.

The changes add two new methods that filter groups and projects based on custom role permissions, specifically focusing on repository access. These filters are then integrated into the search authorization system so that when someone searches for code, the system properly includes results from repositories they can access through their custom roles.

The update also includes comprehensive tests to ensure this new functionality works correctly across different search engines (Elasticsearch and Zoekt) and at different levels (global, group, and project searches). The tests verify that users with custom roles can find content they should have access to, while still being blocked from content they shouldn't see.

References

Related to Support group access for zoekt traversal ids (#557409 - closed)

• Work broken up into 3 MRs
  • code re-organization - !202287 (merged)
  • group access and shared group access support - !201019 (merged)
  • ⭐ custom role :read_code access support - !202293 (merged)

Screenshots or screen recordings

Before	After

How to set up and validate locally

1. enable zoekt in gdk
2. add a custom role to your instance with role = GUEST and ability = View repository code

• GDK_URL/admin/application_settings/roles_and_permissions
• https://docs.gitlab.com/user/custom_roles/

3. create a few nested groups/projects

• public group A <-- shared group access - GUEST
  • public project A
  • private group A
    • private project A
    • private group C <-- shared group access - custom role
      • private project C
  • public group B
    • public project B
    • private project B

4. add the shared group at the levels mentioned above
5. verify that search returns appropriate results. you should always see results from
   • public groups/projects
   • private group C/private project C

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 #557409 (closed)