Use new auth filter in wikis

Description

The wikis query uses the legacy authorization filtering by project ids (global search) and traversal_ids and rejected project list (group search). This is known to produce large, inefficient global and group Elasticsearch queries.

Proposal

Change the query to use by_combined_search_level_and_membership filter and update specs accordingly. by_combined_search_level_and_membership is an existing filter that handles group and project authorization by using a should query to Elasticsearch. This should be introduced behind a feature flag.

Implementation Plan

1. Feature Flag

Create EE-only feature flag search_advanced_wiki_new_auth_filter

2. Update WikiClassProxy (ee/lib/elastic/latest/wiki_class_proxy.rb)

• Add feature flag check in apply_permission_filters
• Create apply_permission_filters_with_new_auth that calls Search::Elastic::Filters.by_search_level_and_membership
• Keep existing logic as fallback when flag disabled
• Ensure search_level, group_ids, project_ids are passed to new filter

3. Handle Wiki-Specific Cases

• Verify group_id field is indexed (already in wiki_config.rb)
• Keep wiki_access_level filter in build_base_query_hash (independent of auth)
• Test group wikis don't appear in project searches and vice versa

4. Update Visibility Specs

Update the following specs to test both flag enabled and disabled scenarios:

• ee/spec/services/ee/search/global_service_wiki_visibility_spec.rb
• ee/spec/services/ee/search/project_service_wikis_visibility_spec.rb
• ee/spec/services/ee/search/group_service_wiki_visibility_spec.rb

5. Add Unit Tests

Add specs in ee/spec/lib/elastic/latest/wiki_class_proxy_spec.rb:

• Global/group/project searches with flag enabled/disabled
• Admin, regular, and anonymous users
• Group and project level wikis
• Verify results match between old and new filters

6. Validation

• Local testing with GDK (enable ES, compare results with/without flag)
• Test with different user types
• Verify query complexity is reduced