## Background The search filter for confidential access still makes use of a huge list of project ids. This is known to be inefficient for both database and Elasticsearch in large SM instances or when a user has access to many groups/projects. ## Proposal Move the [search filters for confidentiality](ee/lib/search/elastic/filters/confidentiality_filters.rb) to use the traversal_id optimization. The filters should gate confidentiality by a combination project_id and traversal_ids that the user has access to (similar to how membership filter is built, see [group membership](https://gitlab.com/gitlab-org/gitlab/blob/894bdb0eff1939cd233101e39925082e9dc62a11/ee/lib/search/elastic/filters.rb#L1265-1265) and [project membership](https://gitlab.com/gitlab-org/gitlab/blob/894bdb0eff1939cd233101e39925082e9dc62a11/ee/lib/search/elastic/filters.rb#L1474-1474) examples). The change should be made behind a derisk feature flag. - [x] convert the project level confidentiality filters - [x] convert the group level confidentiality filters <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> <!-- Please add a label for the type of maintenance as per https://handbook.gitlab.com/handbook/product/groups/product-analysis/engineering/metrics/#work-type-classification -->