Fix search group and project auth for subgroups

What does this MR do and why?

Related to #477814 (closed) #480232 (closed)

Fix a bug with project search discovered in https://gitlab.com/gitlab-com/enablement-sub-department/section-enable-request-for-help/-/issues/107 . While working on it, I found the same bug in group search.

This MR changes how traversal_ids are determined for users for group, group, and project search. The approach moved away from database queries to using a TrieNode for determining permissions in the traversal_ids hierarchy.

Global search

Authorized groups are sent into a TrieNode first to remove duplicates and reduce the traversal_ids list in the ES query. We've seen for our own IDs on GitLab.com, that we have access to top level group gitlab-org and also sub groups within gitlab-org. This optimization was added in a second commit

Group search

traversal_ids are returned in the following order:

• all namespaces searched are checked and allowed if user is a
  • direct member of namespace
  • direct member of an ancestor of namespace
  • any descendent namespaces that user has access to are also allowed

Project search

• all projects searched have their parent namespaces checked and allowed if user is a
  • direct member of the project's parent namespace
  • direct member of an ancestor of project's parent namespace

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

N/A

How to set up and validate locally

1. enable elasticsearch for gdk
2. enable search_query_authorization_refactor feature flag
3. setup a user
4. setup a top level private group - Group A with Project A
5. setup a group the top level - Group A-B with Project A-B
6. setup a group under the sub group - Group A-B-C with project Project A-B-C
7. give user direct access to Group A-B (i tested with access through a shared group)
8. perform a global search for "gdk.test:3000/group-" or "localhost:3000/group-" depending on if you use gdk.test or localhost
9. verify results only come back from Project A-B and Project A-B-C
10. perform a group search under Group A-B
11. verify results only come back from Project A-B and Project A-B-C
12. perform a group search under Group A-B-C
13. verify results only come back from Project A-B-C
14. perform a project search under Project A-B
15. verify results only come back from Project A-B
16. perform a project search under Project A-B-C
17. verify results only come back from Project A-B-C