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.

This makes code to support encrypted runner tokens.
This code also finished previously started encryption
process.

When `force` is set to `true` and `start_branch` is set, the
branch will be ovewritten with the new commit based on the
`HEAD` of the `start_branch`.

This commit includes changes to update the `gitaly-proto` gem.

Sidekiq jobs frequently spawn long-lived child processes to do work.
In some circumstances, these can be reparented to init when sidekiq is
terminated, leading to duplication of work and strange concurrency
problems.

This commit changes sidekiq so that, if run as a process group leader,
it will forward `INT` and `TERM` signals to the whole process group. If
the memory killer is active, it will also use the process group when
resorting to `kill -9` to shut down.

These changes mean that a naive `kill <pid-of-sidekiq>` will now do the
right thing, killing any child processes spawned by sidekiq, as long as
the process supervisor placed it in its own process group.

If sidekiq isn't a process group leader, this new code is skipped.

We've previously exposed ca_file and ssl_version but there are many
possible options that can be used inside tls_options. Instead of
exposing individual ones, simply expose the entire hash so it can
be passed in and we won't have to add things in the future.

This commits add a job that is going to be triggered whenever someone
adds `[serverless deploy-functions]` text into their commit message.

This make it really simple to deploy functions in FaaS-only project.

Fix 'commands applied' messages not being shown when issue is promoted to epic
using slash commands.

Adds EE information to gon
Creates a global vue mixin

In 11.8, we added a fix for the SearchFilesByContent RPC in gitaly to
send back the response in chunks. However, we kept in the old code path
for backwards compatibility. Now that the change is fully deployed, we
can remove that old codepath.

We can reduce a significant number of queries by preloading the
associations for events.

On GitLab.com, for a date that had 456 events, this brought the load
time down from 8.7 to 1.2 s.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/58392

This brings back some of the changes in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20339.

For users using Gitaly on top of NFS, accessing the Git data directly
via Rugged is more performant than Gitaly. This merge request introduces
the feature flag `rugged_find_commit` to activate Rugged paths.

There are also Rake tasks `gitlab:features:enable_rugged` and
`gitlab:features:disable_rugged` to enable/disable these feature
flags altogether.

Part of four Rugged changes identified in
https://gitlab.com/gitlab-org/gitlab-ce/issues/57317.

This change introduces a support for nesting the includes,
allowing to evaluate them in context of the target,
by properly respecting the relative inclusions and user permissions
of another projects, or templates.

Rollback is done similar to Migration for the Hashed Storage.
It also shares the same ExclusiveLease key to prevent both happening
at the same time.

All Hashed Storage related workers now share the same queue namespace
which allows for assigning dedicated workers easily.

We are adding sidekiq workers and service classes to allow to rollback
a hashed storage migration. There are some refactoring involved as well
as part of the code can be reused by both the migration and the rollback
logic.

Fix

ok

Add spec

Fix

ok

Fix

Add changelog

Fix

Add memoization

a

fix

This reverts commit 00675311.

This reverts commit f5201a81, reversing
changes made to 48e6db0d.

source_sha and target_sha are used for merge request pipelines

This reverts merge request !25293

This adds a concern that abstracts the concept of masking a variable,
including the RegEx for validation.

Previously GraphQL field authorization happened like this:

    class ProjectType
      field :my_field, MyFieldType do
        authorize :permission
      end
    end

This change allowed us to authorize like this instead:

    class ProjectType
      field :my_field, MyFieldType, authorize: :permission
    end

A new initializer registers the `authorize` metadata keyword on GraphQL
Schema Objects and Fields, and we can collect this data within the
context of Instrumentation like this:

    field.metadata[:authorize]

The previous functionality of authorize is still being used for
mutations, as the #authorize method here is called at during the code
that executes during the mutation, rather than when a field resolves.

https://gitlab.com/gitlab-org/gitlab-ce/issues/57828

Merge branch '57794-project-template-for-net' of https://gitlab.com/gitlab-org/gitlab-ce into 57794-project-template-for-net

Adds the ground work for writing into
the merge ref refs/merge-requests/:iid/merge the
merge result between source and target branches of
a MR, without further side-effects such as
mailing, MR updates and target branch changes.

Merge branch '57785-create-project-template-for-netlify' of https://gitlab.com/gitlab-org/gitlab-ce into 57785-create-project-template-for-netlify

We set the default value to 9.6.2 since this was the previous default
being used by `stable/postgresql --version=0.7.1` which is used in
auto-deploy-app.

Prior to this change, 35 Gitaly RPCs were allowed. But recently there's
been a renewed interest in performance. By lowering the number of
calls new N + 1's will pop up.

Later commits will add blocks to ignore the raised errors, followed by
an issue for each to be fixed.