updated documentation for Geo

Consider the scenario:

1. The default visibility level is set to internal
2. A user attempts to create a private project within a private group

Previously this would always fail because default_value_for would
overwrite the private visibility setting, no matter what
visibility_level were specified. This was happening because
default_value_for was confused by the default value of 0 specified by
the database schema.

default_value_for attempts to assign the default value in the block by
checking whether the attribute has changed. The problem is that since
the default value by the database was 0, and the user requested 0, this
appeared as though no changes were made. As a result, default_value_for
would always overwrite the user's preference.

To fix this, we remove the use of default_value_for and only set the
visibility level to the default application setting when no preference
has been given at creation time.

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

Enable Get and Update of ci_default_git_depth for
Project API.

Renaming Project#default_git_depth to :ci_default_git_depth
to give more context through the API usage.

Add API documentation

If the origin project has no default_git_depth set (i.e. nil) set the
fork's default_git_depth to 0

Introduce default_git_depth in project's CI/CD settings and set it to
50. Use it if there is no GIT_DEPTH variable specified. Apply this
default only to newly created projects and keep it nil for old ones
in order to not break pipelines that rely on non-shallow clones.

default_git_depth can be updated from CI/CD Settings in the UI, must be
either nil or integer between 0 and 1000 (incl).

Inherit default_git_depth from the origin project when forking projects.

MR pipelines are run on a MR ref (refs/merge-requests/:iid/merge) and it
contains unique commit (i.e. merge commit) which doesn't exist in the
other branch/tags refs. We need to add it cause otherwise it may break
pipelines for old projects that have already enabled Pipelines for merge
results and have git depth 0.

Document new default_git_depth project CI/CD setting

Delete Todos for guest users when project visibility
level is updated to private.

We've already migrated all the legacy artifacts to the new realm,
which is ci_job_artifacts table.
It's time to remove the old code base that is no longer used.

Gitlab::HTTP now resolves the hostname only once, verifies the IP is not
blocked, and then uses the same IP to perform the actual request, while
passing the original hostname in the `Host` header and SSL SNI field.

GitDeduplicationService performs idempotent operations on deduplicated
projects.

Immediate configuration is not ideal for group and instance
level clusters as projects that may never be deployed would
still have Kubernetes namespaces and service accounts created
for them.

As of https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/25586
we now create only the resources that are required for the
project being deployed, at the time of deployment.

Pull mirrors would run the `Projects::AfterImportService`, which would
force a `git gc` each time it finished. This is overkill and not
necessary now that we have refs packed more frequently
(https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27826).

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

Project imports were failing with `undefined method each_with_object for
String` because the import was attempting to parse the LFS Batch API and
failing due to the fact that the Content-Type wasn't a supported format
(e.g. application/vnd.git-lfs+json instead of application/json). We now
parse the body as JSON.

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

Fixes #60425

PackRefs is not an expensive gitaly call - we want to
call it more often (than as part of full `gc`) because
it helps to keep number of refs files small - too many
refs file may be a problem for deployments with
slow storage.

In order to make `LfsImportService` more reusable, we
need to extract the logic inside `ImportService` and
encapsulate it into the service.

This new table will be used to store the external_dashboard_url which
allows users to add a link to their external dashboards (ex Grafana)
to the Metrics dashboard.

Probably useful as we often move these files to "new" files.

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

This reverts merge request !26823

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

- rewords examples starting with 'should'
- rewords examples starting with 'it'

Note: I had to manually fixup "onlies" to "only"

During a project import, it's possible that new branches are created by
the importer to handle pull requests that have been created from forked
projects, which would increment the `pushes_since_gc` value via
`HousekeepingService.increment!` before a full garbage collection gets
to run. This causes HousekeepingService to skip the full `git gc` and
move to the incremental repack mode. To ensure that a garbage collection
is run to pack refs and objects, explicitly execute the task.

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

Both of these were related to groups:

1. We need to preload routes (using the `with_route` scope) if we're
   going to get the group's path.
2. We were counting each group's members separately.

They're in the same commit because the spec for N+1 detection wouldn't
pass with only one of these fixes.

The flag is on by default, but allows us to revert back
to the old behaviour if we encounter any problems.

This is a fix for the Hashed Storage migration and Rollback procedure
to ignore any project-level validation error that can happen in a
long-running instance.

There are many situations where defaults and acceptable values changed
but, because we didn't provide a migration to "valid" attributes, it
can happen that project will not be `valid? => true`.

Because the changes we are making are limited to setting a project as
read_only or changing the storage_level, it's safe to bypass validation.

- Move some specs into contexts
- Let get_slugs method take a parameter and return a specific slug.
- Add rescues when using Addressable::URI.

Exceptions were also simplified from 2 to 1.

`try_to_set_repository_read_only!` is now on the Base class.
Simplified Exception classes from 2 to 1 with a more descriptive name.

This change takes the case where repository doesn't exist on disk
and make it ignore but succeed the step, increasing or decreasing the
version depending on the operation.

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.

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.

When hashed storage is in use, it's helpful to have the project
name associated with the request.

Closes https://gitlab.com/gitlab-org/gitaly/issues/1394