Add the missing check on GraphQL API for project statistics

This exposes `Note`s on Issues & MergeRequests using a
`Types::Notes::NoteableType` in GraphQL.

Exposing notes on a new type can be done by implementing the
`NoteableType` interface on the type. The presented object should
be a `Noteable`.

Adds `set_issue_updated_at` similar to `set_issue_created_at`
permission and cleans up the related permission check in issues
API.

Try to simplify feature flag checks by using policies

There are two cluster hierarchies one for the deployment platform and
one for controllers. The main difference is that deployment platforms do
not check user permissions and only return the first match.

Instance level clusters were already mostly supported, this change adds
admin area controllers for cluster CRUD

This is step one of resolving
https://gitlab.com/gitlab-org/gitlab-ce/issues/56838.

Here is what changed:
- Revert the security fix from bdee9e84.
- Do not leak repository information (tag name, commit) to guests in API
responses.
- Do not include links to source code in API responses for users that do
not have download_code access.
- Show Releases in sidebar for guests.
- Do not display links to source code under Assets for users that do not
have download_code access.

GET ':id/releases/:tag_name' still do not allow guests to access
releases. This is to prevent guessing tag existence.

This is now entirely handled by `create_note`:

1. Project snippets prevent `create_note`.
2. Uploads already only support routing for personal snippets.

This simplifies some policies and access checks, too!

Move Contribution Analytics related spec in spec/features/groups/group_page_with_external_authorization_service_spec to EE

Used to get the variables via the API endpoint
`/projects/:id/pipelines/:pipeline_id/variables`
Signed-off-by: NAgustin Henze <tin@redhat.com>

Add columns to store project creation settings

Add project creation level column in groups
 and default project creation column in application settings

Remove obsolete line from schema

Update migration with project_creation_level column existence check

Rename migrations to avoid conflicts

Update migration methods

Update migration method

This reverts merge request !26823

Move Contribution Analytics related spec in spec/features/groups/group_page_with_external_authorization_service_spec to EE

Chnage method used in model to make it
more efficient database-wise
Add additional spec

Signed-off-by: NRémy Coutable <remy@rymai.me>

Signed-off-by: NRémy Coutable <remy@rymai.me>

Signed-off-by: NRémy Coutable <remy@rymai.me>

Signed-off-by: NRémy Coutable <remy@rymai.me>

As they do not have a permission to read git tag

We can extend the policy in EE for additional behavior

Fixes #56864

This commit includes changes to add `UserAccess#can_create_branch?`
which will check whether the user is allowed to create a branch even
if it matches a protected branch.

This is used in `Gitlab::Checks::BranchCheck` when the branch name
matches a protected branch.

A `push_to_create_protected_branch` ability in `ProjectPolicy` has been
added to allow Developers and above to create protected branches.

The API get projects/:id/traffic/fetches allows user with write
access to the repository to get the number of clones for the
last 30 days.

Due to a bug in `BoardPolicy`, users were getting back a 403 error when
trying to assign users to an assignee list and seeing "Something went
wrong while fetching assignees list". For some reason, the declarative
policy runtime was ignoring the ternary condition.

To work around the issue, we make the project board an explicit
condition check.

Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/9727

Board list policies are also included

This changes the permission check so it uses the policy on Noteable
instead of Project. This prevents bypassing of rules defined in
Noteable for locked discussions and confidential issues.

Also rechecks permissions when reply_to_discussion_id is provided since the
discussion_id may be from a different noteable.

When the external wiki is enabled, the internal wiki link is replaced
by the external wiki url. But the internal wiki is still accessible.
In this change the external wiki will have its own tab in the sidebar
and only if the services are disabled the tab (and access rights)
will not be displayed.

When the parent noteable is not visible to the user (e.g. confidential)
we prevent the user from adding emoji reactions to notes