Teach GitLab not only to merge changes from a merge-request, but also to
apply patches posted to merge-request in a way like `git am` would do -
without merge commit and directly on top of current branch. Which way to
go is selected by user in web UI, and apply patches is the first option.

There are 3 cases:

- only 1 commit is present in MR -> the only available option is to
  apply that single commit as one patch without a merge

  ( There is no need for merge commit in this case at all: information
    about user who applied the patch goes to "Committer" field in resultant
    commit. Avoiding 1 merge per 1 patch results in cleaner history )

  It is also possible to review patch description directly in web UI,
  before doing the actual application, and correct / amend it as needed.

- several commits are present in MR:

  * it is possible to apply the patches directly on top of current
    branch. Again information about who applied what goes to "Committer"
    field.

  * it is possible to merge MR changes with making a merge commit.

    This variant is useful, when patches from a MR do several logical
    steps to reach one goal, and MR description contain cover letter for
    whole patch series.

    in this case original commits stay untouched and resulting merge
    will contain MR author as author, user who accepted MR as committer,
    and cover letter as merge commit message.

    NOTE we avoid useless "Merge branch X into Y" in merge message, and
        just put MR title into merge subject and MR description into merge
        description.

        This way it is more logical with more important information in
        merge subject and thus e.g. more handy to oversee what a merge brings,
        just by it subject, e.g. via looking at updates via

            gitk --first-parent ...

        or via web.

NOTE for pre-generated references to merge-request we now use full MR
    URL, instead of !<MR-n>. Full URLs work everywhere, not only on
    original site where MR was created, or even only in original repo
    and not its fork on the same site.

Conflicts:
	app/services/merge_requests/merge_service.rb

TODO detect whether request comes from China and only then show ICP (?).

We show in small font size the same info that is shown on sign_in page:

    "GitLab Nexedi Edition", "About GitLab" and "About Nexedi"

This is good to have and hereby-introduced about-footer area will be
also used in the next patch for ICP too.

XXX placement of .about-footer to be near bottom is done not very
correctly.

Conflicts:
	app/assets/stylesheets/framework/sidebar.scss

Like Omnibus, SlapOS version does not have init script - nothing to
check here.

This is handy for monitoring tools, which could e.g. periodically call check
tasks and instead of parsing output, rely on exit code.

The way we detect if something failed is via hooking into String#red, and if
anything was ever printed in red - that's an error.

Conflicts:
	lib/tasks/gitlab/check.rake

The default was switched to HTTP in the previous patch, but let's completely
remove SSH option - we support only HTTP for git fetch/push.

Conflicts:
	app/views/shared/_clone_panel.html.haml

Both fetch and push are possible over https, which is selected by http if
gitlab was configured to use https in external url.

This way to reduce security vectors and possible ways to interact with gitlab
we use https only without ssh at all.

Conflicts:
	app/helpers/projects_helper.rb

= GitLab Community Edition + Nexedi patches

[ci skip]

This reverts commit a23ca284.

[ci skip]
Signed-off-by: Rémy Coutable <remy@rymai.me>

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

API: Share projects only with groups current_user can access

Aims to address the issues here: https://gitlab.com/gitlab-org/gitlab-ce/issues/23004

* Projects can be shared with non-existent groups
* Projects can be shared with groups that the current user does not have access to read

Concerns:

The new implementation of the API endpoint allows projects to be shared with a larger range of groups than can be done via the web UI.

The form for sharing a project with a group uses the following API endpoint to index the available groups: https://gitlab.com/gitlab-org/gitlab-ce/blob/494269fc92f61098ee6bd635a0426129ce2c5456/lib/api/groups.rb#L17. The groups indexed in the web form will only be those groups that the user is currently a member of.

The new implementation allows projects to be shared with any group that the authenticated user has access to view. This widens the range of groups to those that are public and internal.

See merge request !2005
Signed-off-by: Rémy Coutable <remy@rymai.me>

Don't send Private-Token headers to Sentry

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/22537

This bumps 'raven' (the Ruby gem we use to send errors to Sentry) to
version 2.0.2. We need 2.0.0 or newer to be able to sanitize HTTP
headers.

See merge request !2004
Signed-off-by: Rémy Coutable <remy@rymai.me>

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

Escape HTML nodes in builds commands in ci linter

This MR removes call to `simple_format` that behaves like `String#html_safe`, thus it passes unescaped HTML tags to the view.

Closes #22541

See merge request !2001
Signed-off-by: Rémy Coutable <remy@rymai.me>

API: disable rails session auth for non-GET/HEAD requests

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

See merge request !1999
Signed-off-by: Rémy Coutable <remy@rymai.me>

Set a restrictive CORS policy for the API

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

See merge request !1998
Signed-off-by: Rémy Coutable <remy@rymai.me>

Enforce the fork_project permission in Projects::CreateService

Projects::ForkService delegates to this service almost entirely, but needed one small change so it would propagate create errors correctly.

CreateService#execute needs significant refactoring; it is now right at the complexity limit set by Rubocop. I avoided doing so in this commit to keep the diff as small as possible.

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

See merge request !1996
Signed-off-by: Rémy Coutable <remy@rymai.me>

Allow the Rails cookie to be used for API authentication

Makes the Rails cookie into a valid authentication token for the Grape
API, and uses it instead of token authentication in frontend code that
uses the API.

Rendering the private token into client-side javascript is a security
risk; it may be stolen through XSS or other attacks. In general,
re-using API code in the frontend is more desirable than implementing
endless actions that return JSON.

Closes #18302

See merge request !1995
Signed-off-by: Rémy Coutable <remy@rymai.me>

[ci skip]
Signed-off-by: Rémy Coutable <remy@rymai.me>

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

Exclude some pending or inactivated rows in Member scopes

An unapproved request or not-yet-accepted invite should not give access rights. Neither should a blocked user be considered a member of anything.

One visible outcome of this behaviour is that owners and masters of a group or project may be blocked, yet still receive notification emails for access requests.

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

See merge request !1994
Signed-off-by: Rémy Coutable <remy@rymai.me>

lib/backup: fix broken permissions when creating repo dir

## What does this MR do?

This MR fixes an issue where gitlab:backup:restore will not work because the repositories directory is set up with bad permissions. The bad permissions will prevent access to the repositories by the git user, causing all kinds of troubles (e.g. gitlab-shell won't install hooks).

## Are there points in the code the reviewer needs to double check?

## Why was this MR needed?

Rake task gitlab:backup:restore would complete successfully, but gitlab:check will report errors and gitlab cannot access repos.

## Screenshots (if relevant)

* repositories.old.1472478726 was created without the fix
* repositories was created with the fix

![gitlab-repo-permissions](/uploads/6cf2de57fe4f1be0bd5b5e1a13234889/gitlab-repo-permissions.png)

## Does this MR meet the acceptance criteria?

- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- Tests
  - [ ] Added for this feature/bug
  - [ ] All builds are passing
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

## What are the relevant issue numbers?

See merge request !6098

Update doorkeeper to 4.2.0

Changelog: https://git.io/v6PnV

See merge request !5881
(cherry picked from commit c5aa31c8)