Improve /project API performance

Closes #31855 and #31937

See merge request !11666

Center loading spinner in issuable filters

Closes #33137

See merge request !11818

Check only a merge ability for protected actions

Closes #32618

See merge request !11648

Ask for an example project for bug reports

See merge request !11819

Add tag_list param to project api

Closes #33000

See merge request !11799

Add API support for pipeline schedule

Closes #30892

See merge request !11307

Allow PostReceivePack to be enabled with Gitaly

Closes gitaly#246

See merge request !11809

* Bugs reported in the GitLab Issue trackers should be reproducible
* Asking reporters to reproduce on GitLab.com is reasonable
  * It lets us know whether the issue still exists in latest
  * It ensures that the steps to reproduce are solid
  * It gives Developers a live example to work from
  * Reporter can verify the fix in the example project once shipped

[skip ci]

Return nil when looking up config for unknown LDAP provider

Closes #29342

See merge request !11804

Revert "Merge branch 'grpc-1.3.4' into 'master'"

See merge request !11813

This reverts merge request !11645

To avoid the use of slow queries, remove some deprecated methods and encourage
the use of ProjectFinder to find projects.

And use it in the API.

Now it is possible to combine the :non_public parameter. This might be useful
when a user wants to know the trending projects they are member of.

The ProjectsFinder and GroupFinder both support the same set of params. And the
`/api/v4/projects` and `/api/v4/group/:id/projects` also support the same set of
params. But they do not match the Finder params. So use a helper method to
transform them.

Instead of applying WHERE on a UNION, apply the WHERE on each of the seperate
SELECT statements, and do UNION on that.

Local tests with about 2_000_000 projects:
 - 1_500_000 private projects
 -    40_000 internal projects
 -   400_000 public projects

For the API endpoint `/api/v4/projects?visibility=private` the slowest query was:

```sql
SELECT "projects".*
FROM "projects"
WHERE ...
```

The original query took 1073.8ms.
The query refactored to UNION of SELECT/WHERE took 2.3ms.

The original query was:

```sql
SELECT "projects".*
FROM "projects"
WHERE "projects"."pending_delete" = $1
  AND (projects.id IN
         (SELECT "projects"."id"
          FROM "projects"
          INNER JOIN "project_authorizations" ON "projects"."id" = "project_authorizations"."project_id"
          WHERE "projects"."pending_delete" = 'f'
            AND "project_authorizations"."user_id" = 23
          UNION SELECT "projects"."id"
          FROM "projects"
          WHERE "projects"."visibility_level" IN (20,
                                                  10)))
  AND "projects"."visibility_level" = $2
  AND "projects"."archived" = $3
ORDER BY "projects"."created_at" DESC
LIMIT 20
OFFSET 0 [["pending_delete", "f"],
       ["visibility_level", 0],
       ["archived", "f"]]
```

The refactored query:
```sql
SELECT "projects".*
FROM "projects"
WHERE "projects"."pending_delete" = $1
  AND (projects.id IN
         (SELECT "projects"."id"
          FROM "projects"
          INNER JOIN "project_authorizations" ON "projects"."id" = "project_authorizations"."project_id"
          WHERE "projects"."pending_delete" = 'f'
            AND "project_authorizations"."user_id" = 23
            AND "projects"."visibility_level" = 0
            AND "projects"."archived" = 'f'
          UNION SELECT "projects"."id"
          FROM "projects"
          WHERE "projects"."visibility_level" IN (20,
                                                  10)
            AND "projects"."visibility_level" = 0
            AND "projects"."archived" = 'f'))
ORDER BY "projects"."created_at" DESC
LIMIT 20
OFFSET 0 [["pending_delete", "f"]]
```

Instead of trying to do the heavy lifting in the API itself, use the existing
features of the ProjectFinder.

The `starred` parameter couldn't be used in combination with `trending` or
`non_public`. But this is changed now.

Add a scope to search for the projects that are starred by a certain user.

The ProjectFinder supports the `non_public` parameter. This can be used to find
only projects the user is member of.

Because this order makes more sense and makes the code easier to read.

To avoid passing parameters double, move all filtering to the `present_projects`
helper.