This is the 1st step for moving Auto DevOps domain into cluster
settings, whether is project or group.

Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/52363

Resolve "Don't check confidential issues for spam"

Closes #56371

See merge request gitlab-org/gitlab-ce!24453

Return the maximum group access level in the projects API

Closes #43684

See merge request gitlab-org/gitlab-ce!24403

Spam checks are meant for content that could be indexed by search
engines. Confidential issues aren't indexed by search engines, so we
don't need to do spam checks for them.

We do need to check for spam when an issue changes from confidential to
public, even if nothing else changed.

Add spec

Add changelog

Port generic Helm upgrade functionality to CE

See merge request gitlab-org/gitlab-ce!23924

Improve MilestonesFinder to accept project and group relations

Closes #47988

See merge request gitlab-org/gitlab-ce!24325

Currently if a project is inside a nested group and a user doesn't have
specific permissions for that group but does have permissions on a
parent group the `GET /projects/:id` API call will return the following
permissions:

```json
permissions: { project_access: null, group_access: null }
```

It could also happen that the group specific permissions are of lower
level than the ones the user has in parent groups. This patch makes it
so that the permission returned for `group_access` is the highest from
amongst the hierarchy, which is (ostensibly) the information that the
API user is interested in for that field.

Refactor checking personal project limits

See merge request gitlab-org/gitlab-ce!24396