Add option to mirror an upstream repository.
Closes internal https://dev.gitlab.org/gitlab/gitlab-ee/issues/279
Depends on gitlab-org/gitlab-shell!29
To do:
- [x] Decide on what user should be the author of the activity feed events. The initial project creator perhaps? That makes sense for personal projects, but less so for group projects, where it's even possible that the creator has since left the team.
- [x] Write specs!
- [x] Write documentation
- [x] Port back relevant commits to CE: gitlab-org/gitlab-ce!1822
----
## Mirror status on project homepage

## Settings navigation item

## Mirroring settings

## Activity feed with new "pushes" (mirror updates)

I have yet to decide on what user should be the author of these events. The initial project creator perhaps? That makes sense for personal projects, but less so for group projects, where it's even possible that the creator has since left the team.
## Warning that branch has diverged from upstream

## Commits heading after failed update

Link send user to the mirroring settings if they are a project admin.
## Mirroring settings after failed update

## New project page

## Import form after failed import
(Screenshot outdated)

Shown when the initial import of a project fails, not when an update of an existing project fails.
cc @dzaporozhets @sytses @JobV
See merge request !51
Fix bug where manually merged branches in a MR would end up with an empty diff
This bug manifested in 8.1 with the refactoring of `RefreshService`. Here's what happens:
1. User create a new branch `foo`.
2. User creates a merge request for `foo`.
3. User merges `foo` into `master` by hand.
4. `RefreshService` reloads the merge request. Since `master` is equivalent to `foo`, this results in an empty diff.
5. `RefreshService` then closes the MR.
This wasn't an issue when you use the normal "Accept Merge Request" flow because the act of clicking the button closes the merge request, so step 4 never happens.
Closes#3314
See merge request !1758
Improve JIRA issue closing
- Zendesk ticket: https://gitlab.zendesk.com/agent/tickets/11034
### Expected behavior
When a merge request has 'Fixes JIRA-1234' in the description the issue should not only be transitioned but also record a comment (regardless of workflow type in JIRA).
### Observed behavior
Depending on the configured workflow a comment may or may not be allowed while transitioning to a new state. In my testing the newest JIRA default workflow did not allow comments while transitioning to 'Done', for example. The 'classic' workflow does, though.
This merge request splits the transition and comment in to two API calls. The advantage is that the comment will be recorded 100% of the time instead of it being dependent on the workflow configuration.
Also, JIRA returns a '204' response code when the transition is successful. I added '204' to the success conditional because we were generating an error in the current configuration even though the transition was successful.
See merge request !45
If a branch is deleted with an open merge request, amended offline, and then pushed again,
GitLab doesn't bother to update the merge request even though the last commit ID and/or
code may have changed. This MR ensures that each push will update any relevant merge
requests and adds a system note if this happens as well.
Closes#2926
- It delegates name, path, gitlab_url, ssh_url_to_repo
- Remove ability to set this parameters using CI API
This fixes GitLab project rename, namespace change, repository rename, etc.