This refactors some of the logic used for protecting default branches,
in particular Project#after_create_default_branch. The logic for this
method is moved into a separate service class. Ideally we'd get rid of
Project#after_create_default_branch entirely, but unfortunately
Project#after_import depends on it. This means it has to stick around
until we also refactor Project#after_import.

For branch protection levels we introduce
Gitlab::Access::BranchProtection, which provides a small wrapper around
Integer based branch protection levels. Using this class removes the
need for having to constantly refer to Gitlab::Access::PROTECTION_*
constants.

This refactors the code used for checking if a user has exceeded the
personal projects limit. As part of this refactor the method has been
renamed from Project#check_limit to "check_personal_projects_limit", as
this name makes it much more clear what the purpose of the method is.
Standalone unit tests have also been added, as before we only had a
single generic validation test that did not cover all cases.

The old implementation of the refactored method also included a `rescue`
statement. This code would only run when a project creator was not set.
The error that would be added wasn't super useful, especially since
there would already be errors for the creator not being present. As none
of the other code in the "check_personal_projects_limit" raises, it has
been removed.

In theory the case could happen that the initial linking of the pool
fails and so do all the retries that Sidekiq performs. This could lead
to data loss.

To prevent that case, linking is done before Gits GC too. This makes
sure that case doesn't happen.

GitLab Pages supports projects hosted under a subgroup, but not subgroup
websites. That means that only the highest-level group supports

i.e.:
You created a group for your engineering department called
`engineering`, a subgroup for all your documentation websites called
`docs`,and a project within this subgroup is called `workflows`.
Your project URL is `https://gitlab.com/engineering/docs/workflows/`.
Once you enable GitLab Pages for this project, the site will live under
`https://engineering.gitlab.io/docs/workflows`.

Previously the nullification wasn't done, as the only caller would later
destroy the model all together. In
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9070 this change
was made. This commit is basically a backport before that MR is merged.

The original intention of `get_build` was as a workaround not to violate
`CodeReuse/ActiveRecord`. `find_by_id` does the exact same thing but
does not violate the rubocop rule.

In the previous code, we locked the project during the migration
scheduling step, which works fine for small setups, but can be
problematic in really big installations.

We now moved the logic to inside the worker, so we minimize the time a
project will be read-only. We also make sure we only do that if
reference counter is `0` (no current operation is in progress).

Re-use operations controller which already handles tracing settings.

Inside of `Projects::ArtifactsController` and
`Projects::BuildArtifactsController` we fetching the build by id using
active record directly which violates `CodeReuse/ActiveRecord` rubocop
rule. Create `get_build` inside of `project` model which does the same
thing.

`project.latest_successful_builds_for(ref)` is being used to find a
single job all the time. This results into us having to call `find_by`
inside of the controller which violates our CodeReuse/ActiveRecord
rubocop rule.

Refactor `project.latest_successful_builds_for(ref)` to
`project.latest_successful_build_for(job_name, ref)` which will execute
the `find_by` inside of the model.

Also create `project.latest_successful_build_for!(job_name, ref)` which
raises an exception instead of returning nil.

On GitLab.com, there are hundreds of projects that have visibility
levels that are inconsistent with the fork or group settings. Most
likely, this happened during a GitLab project import because the
validation was bypassed.  Attempting to migrate these projects to hashed
storage fails even though the migration doesn't touch the visibility
settings. Skipping the visibility validation allows the migration to go
through.

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

We now use `-merge-request` instead of `+merge-request+`
in order to support catch all email addresses

This commits adds a new class that is supposed to represent Grape API
version, like `v3` or `v4`.

- we now use the hierarchy class also for epics
- also rename supports_nested_groups? into supports_nested_objects?
  - move it to a concern

This action doesn't lean on reduplication, so a short call can me made
to the Gitaly server to have the object pool remove its remote to the
project pending deletion.
https://gitlab.com/gitlab-org/gitaly/blob/f6cd55357/internal/git/objectpool/link.go#L58

When an object pool doesn't have members, this would invalidate the need
for a pool. So when a project leaves the pool, the pool will be
destroyed on the background.

Fixes: https://gitlab.com/gitlab-org/gitaly/issues/1415

Removing the pipeline_ci_sources_only feature flag introduced
in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23353

In https://gitlab.com/gitlab-org/release/framework/issues/28 we found
that this method was changed a lot over the years: 43 times if our
calculations were correct. Looking at the method, it had quite a few
branches going on:

    def create_or_update_import_data(data: nil, credentials: nil)
      return if data.nil? && credentials.nil?

      project_import_data = import_data || build_import_data

      if data
        project_import_data.data ||= {}
        project_import_data.data = project_import_data.data.merge(data)
      end

      if credentials
        project_import_data.credentials ||= {}
        project_import_data.credentials =
          project_import_data.credentials.merge(credentials)
      end

      project_import_data
    end

If we turn the || and ||= operators into regular if statements, we can
see a bit more clearly that this method has quite a lot of branches in
it:

    def create_or_update_import_data(data: nil, credentials: nil)
      if data.nil? && credentials.nil?
        return
      else
        project_import_data =
          if import_data
            import_data
          else
            build_import_data
          end

        if data
          if project_import_data.data
            # nothing
          else
            project_import_data.data = {}
          end

          project_import_data.data =
            project_import_data.data.merge(data)
        end

        if credentials
          if project_import_data.credentials
            # nothing
          else
            project_import_data.credentials = {}
          end

          project_import_data.credentials =
            project_import_data.credentials.merge(credentials)
        end

        project_import_data
      end
    end

The number of if statements and branches here makes it easy to make
mistakes. To resolve this, we refactor this code in such a way that we
can get rid of all but the first `if data.nil? && credentials.nil?`
statement. We can do this by simply sending `to_h` to `nil` in the right
places, which removes the need for statements such as `if data`.

Since this data gets written to a database, in ProjectImportData we do
make sure to not write empty Hash values. This requires an `unless`
(which is really a `if !`), but the resulting code is still very easy to
read.

This implements Repository#ambiguous_ref? and checks if a ref is
ambiguous before trying to resolve the ref in Project#protected_for?