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

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.

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

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

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

This reflects how we now create or update

AFAIK the only relevant place is Projects::CreateService, this gets
called when user creates a new project, forks a new project and does
those things via the api.

Also create k8s namespace for new group hierarchy
when transferring project between groups

Uses new Refresh service to create k8s namespaces

- Ensure we use Cluster#cluster_project

If a project has multiple clusters (EE), using Project#cluster_project
is not guaranteed to return the cluster_project for this cluster. So
switch to using Cluster#cluster_project - at this stage a cluster can
only have 1 cluster_project.

Also, remove rescue so that sidekiq can retry

This removes the `ForkedProjectLink` model that has been replaced by
the `ForkNetworkMember` and `ForkNetwork` combination. All existing
relations have been adjusted to use these new models.

The `forked_project_link` table has been dropped.

The "Forks" count on the admin dashboard has been updated to count all
`ForkNetworkMember` rows and deduct the number of `ForkNetwork`
rows. This is because now the "root-project" of a fork network also
has a `ForkNetworkMember` row. This count could become inaccurate when
the root of a fork network is deleted.

Cleanup code, and refactor tests that still use Rugged. After this, there should
be no Rugged code that access the instance's repositories on non-test
environments. There is still some rugged code for other tasks like the
repository import task, but since it doesn't access any repository storage path
it can stay.

Direct disk access is done through Gitaly now, so the legacy path was
deprecated. This path was used in Gitlab::Shell however. This required
the refactoring in this commit.

Added is the removal of direct path access on the project model, as that
lookup wasn't needed anymore is most cases.

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

Closes #37462.

Prior to this change, this method was called add_namespace, which broke
the CRUD convention and made it harder to grep for what I was looking
for. Given the change was a find and replace kind of fix, this was
changed without opening an issue and on another feature branch.

If more dynamic calls are made to add_namespace, these could've been
missed which might lead to incorrect bahaviour. However, going through
the commit log it seems thats not the case.

We'd need to keep track of project full path otherwise directory tree created with hashed storage enabled cannot be usefully imported using the import rake task.

Because of a change in GitLab 9.5.4 to prevent users from assuming control of
a repository already on disk, the import task broke. Imports would fail with
the message, "There is already a repository with that name on disk".

This change skips the validation when the import is done from the
command-line.

Closes #37682

There are some redundancies in the validation steps, and that is to
preserve current error messages behavior

Also few specs have to be changed in order to fix madness in validation
logic.

Only admins have the ability to create a project in another user's personal
namespace. Prior to this commit, we were explicitly adding them as masters to
the project. However, admins already have access (by virture of being admins),
so this is unnecessary.

Remove superfluous lib: true, type: redis, service: true, models: true, services: true, no_db: true, api: true
Signed-off-by: NRémy Coutable <remy@rymai.me>

When an admin creates a project in the namespace of a user, that user
automatically gains master access to that project.

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