CE to EE for 8.10.0-rc1

Unresolved conflicts:

- `app/views/projects/_home_panel.html.haml`
- `app/views/shared/_clone_panel.html.haml`
- `app/helpers/projects_helper.rb`

@iamphill Could you please resolve the conflicts introduced by gitlab-org/gitlab-ce!4989 in `app/views/projects/_home_panel.html.haml` and check that project headers look good? Thanks in advance!

@patricio Could you please resolve the conflicts introduced by gitlab-org/gitlab-ce!4696 in `app/helpers/projects_helper.rb` and `app/views/shared/_clone_panel.html.haml`? Thanks in advance!

I need this to be able to release 8.10.0-rc1!

See merge request !528

[ci skip]

Revert "Merge branch 'fix_stale_last_owner' into 'master'"

This reverts merge request !529

Accidentally merged my own MR before review. Reverting and resubmitting. 

See merge request !530

This reverts merge request !529

Prevent stale data in LDAP group sync last owner check

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

Customers were reporting that LDAP group sync would occasionally remove the last owner of a group. This didn't seem right (we have tests for this) so I dug in to see what was going on. Previously `owners` was a memoized method which was the reason for stale data. Now, it's an AR association and the same problem applies. The easiest solution is to reload the model before checking for last owner. 

See merge request !529

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

Check fast-forward more precisely

The original issue is that (#260), some people want to be able to merge
a fast-forward MR regardless it's rebased or not. The previously
check for this: `target_sha == source_sha_parent`, assumes that the
questioning MR has a linear history (i.e. it's rebased), therefore
we could do a fast-forward merge. However, we could also do fast-forward
merge if the MR has already merged target branch (i.e. it's merged).

This MR would allow them to merge any fast-forward MR regardless rebased
or not.

But actually this breaks some assumption. In the option of:

> Merge commit with semi-linear history
>> A merge commit is created for every merge, but merging is only
>> allowed if the branch has been rebased. This way you get a history
>> that reads linearly (as with fast-forward merges), with the addition
>> of merge commits.
>> When the branch has not been rebased, the user is given the option to do
>> so.

It clearly says: `merging is only allowed if the branch has been rebased`
This MR would break this assumption. The same applies to:

> Fast-forward merge
>> No merge commits are created and all merges are fast-forwarded, which
>> means that merging is only allowed if the branch has been rebased.
>> When the branch has not been rebased, the user is given the option to do
>> so.

This means that rebase and FF are two separated concept and we're
mixing them here. We should probably update the wordings and perhaps
provide another option if we want to keep all the workflows.

My own thought is actually, allowing only FF merge might make little
sense. Allowing only FF *and* rebased (linear history) would make more
sense. That means I think the original behaviour actually makes more
sense, just that the wordings are wrong. i.e. They could be FF merged,
but that's not the point, we still want you to rebase this branch!

On the other hand, I am not against adding a new option for this
behaviour either. People have different workflows, and I think it makes
sense to allow any workflows which Git provided.

Either way, I think some wordings should be changed.

By the way, could we write a test for this?

Fixes #260

/cc @DouweM 

See merge request !454

Cancel creating or editing note by hitting Escape

/cc @rspeicher 

See merge request !5075

Don't expose repository credentials when raising error on mirror update.

REF: https://gitlab.com/gitlab-com/support-forum/issues/816

See merge request !527

Remove duplicate templates that are lowercase

See merge request !5114

Throttle the update of `project.pushes_since_gc` to 1 minute

## What does this MR do?

Throttle the update of `project.pushes_since_gc` to alleviate DB load

## What are the relevant issue numbers?

Relates to #15094

## 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~~
  - [x] All builds are passing
- [x] 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)


See merge request !5083

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

Fix diff comments not showing up in activity feed

## What does this MR do?

It fixes the detection of note events to check for `Note` and `LegacyDiffNote`.

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

No? /cc @DouweM (since I believe you introduced `LegacyDiffNote`

## Why was this MR needed?

To fix #19092.

## What are the relevant issue numbers?

Fixes #19092.

## Does this MR meet the acceptance criteria?

- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- Tests
  - [x] Added for this feature/bug
  - [ ] All builds are passing
- [x] 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)

See merge request !5069

Bump GITLAB_SHELL_VERSION to 3.2.0

Bump GITLAB_SHELL_VERSION to 3.2.0

Needed for !4696 to properly work.

Blocked by gitlab-org/gitlab-shell!62

See merge request !5101

Allow `?`, or `&` for label names

Closes #18727 

See merge request !4724

Fixing URL validation for import_url on projects

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

This MR fixes problems related to bypassing `import_url` validation on projects. This makes sure the URL is properly validated so we don't enter crap and fail while running workers that handle this URL.

It also adds a migration to fix current invalid `import_url`s

See merge request !4753

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

Mark the import as failed if a temporary or unknown error happened.

https://gitlab.com/gitlab-com/support-forum/issues/816

I've seen some users have reported that the updated of their mirror
repositories is being stuck, it basically happens because a temporary or
unknown error happened and the import status was kept in `started`
instead of being marked as `failed`.

See merge request !526

Add and update .gitignore & .gitlab-ci.yml templates for 8.10



See merge request !5107

Rename git hooks to push rules

Fixes https://gitlab.com/gitlab-org/gitlab-ee/issues/189

I also created an issue for removing deprecated API https://gitlab.com/gitlab-org/gitlab-ee/issues/755

See merge request !523

Add more debug info to import/export and memory killer

This should help debug https://gitlab.com/gitlab-org/gitlab-ce/issues/19124 further

See merge request !5108

Add the update guide from 8.10 CE to 8.10 EE



See merge request !524

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

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

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