Group dropdown on New Project page respects visibility settings

What does this MR do and why?

When the setting 'restricted visibility setting' has 'private' checked, users can not create projects in private groups. However, the 'Groups' dropdown on the New Project page did show these private groups. So users could select the invalid group, submit the form and see an error message. This MR will prevent this to happen: the invalid groups are not rendered in the dropdown.

Related to #384358 (closed)

Implementation

The dropdown is using a GraphQL query to retrieve the group list. This query is using ::Groups::AcceptingProjectCreationsFinder. That class is modified: it will not return groups that have visibility_level equal to Gitlab::CurrentSetting.restricted_visibility_levels.

Database queries

The query is very large so I will not include it here

• Current master (i.e. no filtering on visibility_level)
• This branch

For both query plans, there are some recommendations for both the query on master and on this branch. But I think it is acceptable:

• The query is very complex and optimized for performance
• The WHERE clause on master already has this filter: "namespaces"."type" = 'Group' AND ("namespaces"."project_creation_level" IN (2, 1) OR "namespaces"."project_creation_level" IS NULL), adding another 'where' clause on namespaces table will not make the query worse
• The query plan on master and this branch did not change

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

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Preparation:

1. As an Administrator user, create a new private group and add one non-admin user to it (for example reported_user_9)
2. Ensure the setting "Restricted visibility levels" is set to private:
   • Change this in the GitLab admin area: /admin/application_settings/general

Test:

• Use impersonate feature to switch to the non-admin user from the Preparation step 1 (for exampe reported_user_9)
• Go to new project page: /projects/new
• The groups dropdown should not list the name of the created group from Preparation step 1
• Login as administrator
• Go to new project page: /projects/new
• The groups dropdown should list the name of the created group from Preparation step 1