Apply wording from https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24834#note_138592349Signed-off-by: NJuergen Kosel <juergen.kosel@gmx.de>

Apply of the following suggestions:
- https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24834#note_137860004
- https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24834#note_137860005
- https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24834#note_137860006Signed-off-by: NJuergen Kosel <juergen.kosel@gmx.de>

As requested in issue https://gitlab.com/gitlab-org/gitlab-ce/issues/57062
describe how to set up a push mirror repository at GitLab.
Signed-off-by: NJuergen Kosel <juergen.kosel@gmx.de>

This got merged up somewhere in the process of merging dev.gitlab.org
and GitLab.com back together.

[ci skip]

In commit 6fa5fd85 the `require: false`
was removed to ensure the Gem was loaded at run time. Unfortunately, the
`require` necessary for the rubyzip Gem is "zip" and not "rubyzip". As a
result, Bundler would not require the Gem. This meant that we would
still run into constant errors when referring to `Zip::File`.

[ci skip]

pages:deploy step was failing with the following error:

```
unitialized constant SafeZip::Extract::Zip
```

Since license_finder already pulls in rubyzip, we can make it
a required gem. We also use the scope operator to make the reference to
Zip::File explicit.

[ci skip]

[ci skip]

Fix a JS race in a spec

Closes #56860

See merge request gitlab-org/gitlab-ce!24684

When a user is a guest user, and the "Public Pipeline" is set to false
inside of "Settings > CI/CD > General" the commit status in the project
dashboard should not be shown.

When moving a project, it's possible that some users who had
access to the project in old path can not access the project
in the new path.

Because `project_authorizations` records are updated asynchronously,
when we send the notification about moved project the list of project
team members contains old project members, we want to notify all these
members except the old users who can not access the new location.

To prevent an OAuth2 covert redirect vulnerability, this commit adds and
uses an alias for the GitHub and BitBucket OAuth2 callback URLs to the
following paths:

GitHub: /users/auth/-/import/github
Bitbucket: /users/auth/-/import/bitbucket

This allows admins to put a more restrictive callback URL in the OAuth2
configuration settings. Instead of https://example.com, admins can now use:

https://example.com/users/auth

It's possible but not trivial to change Devise and OmniAuth to use a
different prefix for callback URLs instead of /users/auth. For now,
aliasing the import URLs under the /users/auth namespace should suffice.

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

LFS uploads are handled in concert by workhorse and rails. In normal
use, workhorse:

* Authorizes the request with rails (upload_authorize)
* Handles the upload of the file to a tempfile - disk or object storage
* Validates the file size and contents
* Hands off to rails to complete the upload (upload_finalize)

In `upload_finalize`, the LFS object is linked to the project. As LFS
objects are deduplicated across all projects, it may already exist. If
not, the temporary file is copied to the correct place, and will be
used by all future LFS objects with the same OID.

Workhorse uses the Content-Type of the request to decide to follow this
routine, as the URLs are ambiguous. If the Content-Type is anything but
"application/octet-stream", the request is proxied directly to rails,
on the assumption that this is a normal file edit request. If it's an
actual LFS request with a different content-type, however, it is routed
to the Rails `upload_finalize` action, which treats it as an LFS upload
just as it would a workhorse-modified request.

The outcome is that users can upload LFS objects that don't match the
declared size or OID. They can also create links to LFS objects they
don't really own, allowing them to read the contents of files if they
know just the size or OID.

We can close this hole by requiring requests to `upload_finalize` to be
sourced from Workhorse. The mechanism to do this already exists.

RubyZip allows us to perform strong validation of
expanded paths where we do extract file.

We introduce the following additional checks
to extract routines:

1. None of path components can be symlinked,
2. We drop privileges support for directories,
3. Symlink source needs to point within the target directory,
   like `public/`,
4. The symlink source needs to exist ahead of time.

This changes the permission check so it uses the policy on Noteable
instead of Project. This prevents bypassing of rules defined in
Noteable for locked discussions and confidential issues.

Also rechecks permissions when reply_to_discussion_id is provided since the
discussion_id may be from a different noteable.

Since we needed to bump the version to 13 in the backports,
and we know that an MR on master also bumped it
to 13, bump to 14 to ensure that when a customer
upgrades to the most recent release, the markdown
gets recalcuated as necessary.

Such as those with IDN homographs or embedded
right-to-left (RTLO) characters.

Autolinked hrefs should be escaped

Group guests will only be displayed merge requests to
projects they have a access level to, higher than Reporter.

Visible projects will still display the merge requests to Guests

When the external wiki is enabled, the internal wiki link is replaced
by the external wiki url. But the internal wiki is still accessible.
In this change the external wiki will have its own tab in the sidebar
and only if the services are disabled the tab (and access rights)
will not be displayed.

Fixes #54721

When the parent noteable is not visible to the user (e.g. confidential)
we prevent the user from adding emoji reactions to notes