1. In the context of protected branches.

2. Test this behaviour.

1. These versions of PhantomJS don't support `PATCH` requests, so we use
   a `POST` with `_method` set to `PATCH`.

1. The model now contains this humanization data, which is the once
   source of truth.

2. Previously, this was being listed out in the dropdown component as well.

1. Remove `Project#developers_can_push_to_protected_branch?` since it
   isn't used anymore.

2. Remove `Project#developers_can_merge_to_protected_branch?` since it
   isn't used anymore.

1. So it works with the new data model for protected branch access levels.

1. Get the existing spec passing.

2. Add specs for all the access control options, both while creating and
   updating protected branches.

3. Show a flash notice when updating protected branches, primarily so
   the spec knows when the update is done.

1. Reuse the same dropdown component that we used for updating these
   settings (`ProtectedBranchesAccessSelect`). Have it accept options
   for the parent container (so we can control the elements it sees) and
   whether or not to save changes via AJAX (we need this for update, but
   not create).

2. Change the "Developers" option to "Developers + Masters", which is
   clearer.

3. Remove `developers_can_push` and `developers_can_merge` from the
   model, since they're not needed anymore.

1. The crux of this change is in `UserAccess`, which looks through all
   the access levels, asking each if the user has access to push/merge
   for the current project.

2. Update the `protected_branches` factory to create access levels as
   necessary.

3. Fix and augment `user_access` and `git_access` specs.

1. Move to dropdowns instead of checkboxes. One each for "Allowed to
   Push" and "Allowed to Merge"

2. Refactor the `ProtectedBranches` coffeescript class into
   `ProtectedBranchesAccessSelect`.

3. Modify the backend to accept the new parameters.

1. Improve error handling while creating protected branches.

2. Modify coffeescript code so that the "Developers can *" checkboxes
   send a '1' or '0' even when using AJAX. This lets us keep the backend
   code simpler.

3. Use services for both creating and updating protected branches.
   Destruction is taken care of with `dependent: :destroy`

- And hook up their associations.

1. Remove the `developers_can_push` and `developers_can_merge` boolean
   columns.

2. Add two new tables, `protected_branches_push_access`, and
   `protected_branches_merge_access`. Each row of these 'access' tables is
   linked to a protected branch, and uses a `access_level` column to
   figure out settings for the protected branch.

3. The `access_level` column is intended to be used with rails' `enum`,
   with `:masters` at index 0 and `:developers` at index 1.

4. Doing it this way has a few advantages:

   - Cleaner path to planned EE features where a protected branch is
     accessible only by certain users or groups.

   - Rails' `enum` doesn't allow a declaration like this due to the
     duplicates. This approach doesn't have this problem.

       enum can_be_pushed_by: [:masters, :developers]
       enum can_be_merged_by: [:masters, :developers]

Cache the commit author in RequestStore to avoid extra lookups in PostReceive

See merge request !5537

Merge branch '17073-tagscontroller-index-is-terrible-response-time-goes-up-to-5-seconds' into 'master'

Update to gitlab_git 10.4.1 and take advantage of preserved Ref objects

See merge request !5536

Reduce number of queries made for merge_requests/:id/diffs

## What does this MR do?
It reduces the number of DB queries made while processing and rendering MR notes.

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

## Why was this MR needed?
For `https://staging.gitlab.com/gitlab-org/gitlab-ce/merge_requests/3142/diffs.json`, for each note we make number of DB queries, almost all of them are handled by the AR caching layer, but they seem to add up a few seconds. Testing on staging, calling `merge_requests/3142/diffs.json` was reduced to ~5.5 seconds from ~8 seconds.

## What are the relevant issue numbers?
N/A

## Screenshots (if relevant)
N/A

## 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~~
- [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 !5551

Replace ci icons with slightly thicker ones

## What does this MR do?
Adds updated CI icons

## Why was this MR needed?
New CI icons were a tad too thin

## What are the relevant issue numbers?
Closes #20089 

## Screenshots (if relevant)
![Screen_Shot_2016-07-26_at_8.59.28_AM](/uploads/35671085829fd64f8a9cf98704661ece/Screen_Shot_2016-07-26_at_8.59.28_AM.png)

See merge request !5475

Remove project which can't be pulled while seeding

This project can't be pulled from GH when running `SIZE=20 rake dev:setup`

[ci skip]

See merge request !5559

[ci skip]

Add a log message when a project is scheduled for destruction for debugging

We have a lot of projects that are in `pending_delete` state. It's not clear whether they were ever scheduled for destruction, or whether Sidekiq just dropped the job due to `MemoryKiller` or some other reason.

Also this will provide a record of which user destroys a project.

#20365 

See merge request !5540

Implement #3243 New Issue by email

So we extend Gitlab::Email::Receiver for this new behaviour,
however we might want to split it into another class for better
testing it.

Another issue is that, currently it's using this to parse project
identifier:

    Gitlab::IncomingEmail.key_from_address

Which is using:

    Gitlab.config.incoming_email.address

for the receiver name. This is probably `reply` because it's used
for replying to a specific issue. We might want to introduce another
config for this, or just use `reply` instead of `incoming`.

I'll prefer to introduce a new config for this, or just change
`reply` to `incoming` because it would make sense for replying to
there, too.

The email template used in tests were copied and modified from:
`emails/valid_reply.eml` which I hope is ok.

/cc @DouweM #3243

See merge request !3363

Merge branch '20308-fix-title-that-is-show-in-the-dropdown-toggle-button-on-projects-branches' into 'master'

Fix the title of the toggle dropdown button

## What does this MR do?

Fix the dropdown-button toggle displaying the correctly title.

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

See if the title is displaying correctly and if the code is acceptable.

## Why was this MR needed?

When you choose `Last updated` it should display the title `Last updated` instead of `Recently updated`. This fix makes this correctly displays the title.

## What are the relevant issue numbers?
Closes #20308.

## Screenshots (if relevant)
![filter-gitlab-ce](/uploads/52838679d134d57c6ff6120260806fda/filter-gitlab-ce.gif)

## Does this MR meet the acceptance criteria?

- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- Tests
  - [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 !5515

Reduce instrumentation overhead

## What does this MR do?

This MR reduces the overhead of instrumented methods. See the commit message of 905f8d76 for more information.

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

Not that I can think of.

## Why was this MR needed?

The overhead of method call instrumentation was too great.

## Does this MR meet the acceptance criteria?

- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] ~~[Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)~~
- [x] ~~API support 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 !5550

Before when you choose the way of `sort` instead it display the title correctly it was just apply the humanize helper in sort value.

E.g.

When you choose `Last updated` it should display the title `Last updated` instead of `Recently updated`. This fix makes this correctly displays the title.

Change the implementation of the `link_to` `filter_branches_path`

- Change the value of the `params[:sort]` in `link_to`. E.g. instead of using `'recently_updated'` is now using `sort_value_recently_updated`.

- Change the values of the case in the `branches_sorted_by` method for the values it receives in the `params[:sort]` that are: `nil`, `'name'`, `'updated_desc'`, `'updated_asc'`.

This reduces the overhead of the method instrumentation code primarily
by reducing the number of method calls. There are also some other small
optimisations such as not casting timing values to Floats (there's no
particular need for this), using Symbols for method call metric names,
and reducing the number of Hash lookups for instrumented methods.

The exact impact depends on the code being executed. For example, for a
method that's only called once the difference won't be very noticeable.
However, for methods that are called many times the difference can be
more significant.

For example, the loading time of a large commit
(nrclark/dummy_project@81ebdea5df2fb42e59257cb3eaad671a5c53ca36)
was reduced from around 19 seconds to around 15 seconds using these
changes.

Add commit stats

## What does this MR do?
When getting commit by SHA in api it returns commit stats

## Are there points in the code the reviewer needs to double check?
Not sure about test I added do we need separate test or we can just shove stats assertion in test above

## Why was this MR needed?
So api users/clients can get statistics on single commit

## What are the relevant issue numbers?
#20307 

## Screenshots (if relevant)

## Does this MR meet the acceptance criteria?

- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [x] API support added
- Tests
  - [x] 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 !5517

Added update guide for 8.11

## What does this MR do?

I need to add notes about Elastic on EE side. To not create ugly conflicts in the future and to not duplicate work I created it here first.

I followed this guide https://gitlab.com/gitlab-org/release-tools/blob/master/doc/release-candidates.md#gitlab-ce

See merge request !5545

* upstream/master: (45 commits)
  Replace reject_blocked with reject_blocked! in callbacks.
  Fix Project#to_param to keep invalid project suitable for use in URLs
  Update CHANGELOG
  Add feature specs for edit project settings
  Fix renaming repository when name contains invalid chars under settings
  Change requests_profiles resource constraint to catch virtually any file
  Allow skipping users in autocomplete
  Fix typo in CHANGELOG
  Update CHANGELOG
  Respective cache is now expired when creating a new branch
  Update CHANGELOG
  Unify HTML format in static error pages
  Make error pages responsive design
  Move color-logic into HipchatService#HipchatService
  Depened on exact version of SimpleCov when patched
  Refactor spam validation to a concern that can be easily reused and improve legibility in `SpamCheckService`
  Refactor `SpamCheckService` to make it cleaner and clearer.
  Submit all issues on public projects to Akismet if enabled.
  Submit new issues created via the WebUI by non project members to Akismet for spam check.
  Upgrade Bullet from 5.0.0 to 5.2.0.
  ...

In a PostReceive task with 697 commits (8.9 RC1 -> RC8), looking up
the commit author takes about 10% of the time. Caching this information
in RequestStore saves a few seconds from the overall processing time.

Improves #18663

Replace reject_blocked with reject_blocked! in skipped callbacks.

`reject_blocked!` was introduced in c9def945, I can't find any references to `reject_blocked` ever existing.

See merge request !5532

In Rails 4.2 and below, skipping callbacks (skip_before_action, skip_after_action, etc.) that use methods which do not exist will not throw any errors.

On the other hand, Rails 5 does. See https://github.com/rails/rails/pull/19029

After testing with Rails 5 I noticed there are some methods that don't actually exist (because they were renamed, usually), this fixes a few instances of those.

reject_blocked! was introduced in c9def945, I can't find any references to reject_blocked ever existing.

Submit new issues created via the WebUI or API to Akismet for spam check on public projects.

## What does this MR do?

Submit new issues created via the WebUI by non project members to Akismet for spam check.

## Why was this MR needed?

Support for Akismet was added only to the API with !2266. This MR builds on that functionality to also check issues submitted via the WebUI for spam.

## What are the relevant issue numbers?

Related to:

- #5573 
- #5932 
- gitlab-com/infrastructure#14
- gitlab-com/support#61
- !2266

cc @stanhu @MrChrisW 

See merge request !5333