Advanced user search: update filtering by project and group

What does this MR do and why?

Why

As part of advanced user search (behind a feature flag), we need to provide results that make sense from a UX perspective. We have done some UX work to establish:

If I search for users and select a group, which users do I expect to see in the list?

and

If I search for users and select a project, which users do I expect to see in the list?

What

Update the way we filter for namespaces to achieve the expected results from a UX perspective.

We are following the principles of project and group membership to establish filtering:

Filter criteria

From @nickbrandt:

Selecting a group

I expect User results with the following criteria...

• Users that are members within the Group or any Sub-groups of the selected group
• Users that are members of any projects that are within the Group or Sub-groups of the selected group
• Only users of these groups/projects that I either have access to (in the case they are private) or that are public
  • This can include shared groups (but not descendants/ancestors of those groups)

Selecting a project

I expect User results with the following criteria...

• Users that are members of the selected project
• Only users of the project that I either have access to (in the case it is private) or that are public
  • Note: If I'm able to select this project, that would assume I either have access (it is visible for my selection) or it is public. So I don't see a scenario where I would be able to select a project to filter, but not see some of its members as results.

How

Instead of relying on the namespace_ancestry_ids field in elasticsearch, get valid users and do an elastic terms filter on id.

This is done for the following reasons:

1. The namespace_ancestry_ids field is on membership only. This means that any logic containing shared or public groups or authorized projects would be hard to do in elasticsearch.
2. Updating the namespace_ancestry_ids field to account for all kinds of authorization would be a bad idea because we would need to listen for updates on multiple tables and keep elasticsearch up to date.
3. There are existing, well-defined methods that get authorized users for projects and groups that we can leverage.
4. A single terms query is better performing than a prefix query for every possible namespace (there could be 100+ for one search).

Screenshots or screen recordings

Example query on local:

Prefix query before:

How to set up and validate locally

• Ensure elasticsearch is running
• Disable the advanced user search feature flag: Feature.disable(:advanced_user_search)
• Do a group-level search and take note of the results returned
• Do a project-level search and take note of the results returned

• Do a global-level search and take note of the results returned
• Enable the advanced user search feature flag: Feature.enable(:advanced_user_search)
• Do a group-level search and take note of the results returned
• Do a project-level search and take note of the results returned

• Do a global-level search and take note of the results returned

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Related to #377587 (closed)