Removes permanent redirects, this means that redirects will only be
possible as long as the old route isn't taken by a new project/group.

We also delete some unused code related to the aforementioned feature.

In GitLab EE, a GitLab instance can be read-only (e.g. when it's a Geo
secondary node). But in GitLab CE it also might be useful to have the
"read-only" idea around. So port it back to GitLab CE.

Also having the principle of read-only in GitLab CE would hopefully
lead to less errors introduced, doing write operations when there
aren't allowed for read-only calls.

Closes gitlab-org/gitlab-ce#37534.

This is used in EE for the storage migration, and we want to use this
in CE as well to be able to migrate projects to hashed_storage.

This is an amalgamation of:

* Cory Hinshaw: Initial implementation !5552
* Rémy Coutable: Updates !9350
* Nick Thomas: Resolve conflicts and add ED25519 support !13712

- Adds a new `ProjectMovedError` class to encapsulate that error
  condition. Inherits from `NotFoundError` so existing rescues should
  continue to work.
- Separating that condition out of `NotFoundError` allowed us to
  simplify the `raise_not_found` helper and avoid repeating the literal
  string.
- Spec makes use of `ERROR_MESSAGES` hash to avoid repeating literal
  error message strings.

Because it is sometimes never used.

https://gitlab.com/gitlab-org/gitlab-ce/commit/57e3e942de1adef2c8621905370f07d7da7870c4

I changed it to a separate condition rather than depending on the order of the case-when statements to prevent this mistake again.

And refactor to self-document a little better.

No external behavior change.

This allows `GitHttpController` to set the HTTP status based on the type of error. Alternatively, we could have added an attribute to GitAccessStatus, but this pattern seemed appropriate.

* The spec has 7 failures at this point
* Specify rendered error messages
* Render the GitAccess message rather than “Access denied”
* Render the Not Found message provided by GitAccess, instead of a custom one
* Expect GitAccess to check the config for whether Git-over-HTTP pull or push is disabled, rather than doing it in the controller
* Add more thorough testing for authentication
* Dried up a lot of tests
* Fixed some broken tests

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

and move those checks to be private. Feedback:

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7383#note_20285012

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7383#note_20285279

1. Starting version 2.11, git changed the way the pre-receive flow works.

  - Previously, the new potential objects would be added to the main repo. If the
    pre-receive passes, the new objects stay in the repo but are linked up. If
    the pre-receive fails, the new objects stay orphaned in the repo, and are
    cleaned up during the next `git gc`.

  - In 2.11, the new potential objects are added to a temporary "alternate object
    directory", that git creates for this purpose. If the pre-receive passes, the
    objects from the alternate object directory are migrated to the main repo. If
    the pre-receive fails the alternate object directory is simply deleted.

2. In our workflow, the pre-recieve script (in `gitlab-shell) calls the
   `/allowed` endpoint, which calls out directly to git to perform
   various checks. These direct calls to git do _not_ have the necessary
   environment variables set which allow access to the "alternate object
   directory" (explained above). Therefore these calls to git are not able to
   access any of the new potential objects to be added during this push.

3. We fix this by accepting the relevant environment variables
   (GIT_ALTERNATE_OBJECT_DIRECTORIES, GIT_OBJECT_DIRECTORY) on the
   `/allowed` endpoint, and then include these environment variables while
   calling out to git.

4. This commit includes (whitelisted) these environment variables while making
   the "force push" check. A `Gitlab::Git::RevList` module is extracted to
   prevent `ForcePush` from being littered with these checks.

we don't have to check for deploy key for downloading
because deploy key could certainly download when it
could already read the project.

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7383#note_19578626

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7383#note_19579483