1. We might need to update/delete access levels that were created in
   this `update` call without a page refresh.

2. The JS relies on the JSON response for the IDs of the newly created
   access level records.

- Using the `allow_destroy` option for `accepts_nested_attributes_for`

1. No need to change the spec for `UserAccess#can_push_to_branch?` for
   EE anymore.

2. Make the `dropdowns_helper` change additive to CE, so as to reduce
   the potential for merge conflicts.

- In 5b92c54319cd0e10f879a35bf6aab85a8e04e540, we destroyed all the
  default access levels for a factory-created protected branch.

- Inadvertently, we also destroyed all spec-created access levels,
  leading to a number of failures, which should now be fixed.

- As part of gitlab-org/gitlab-ce!5824, the `protected_branches` factory
  creates default `MASTER` access levels for merging and pushing.

- Some specs rely on the condition that no pre-existing access levels
  exist when a protected branch is created, and these specs were
  failing.

- Added a factory trait to remove the default access levels.

- Project needs to be loaded before `find_users` is called.

1. Check if a project is readable by the current user when fetching
   users for autocomplete.

2. Remove duplication relating to gon variables in
   `ProtectedBranchesController`

3. Remove unnecessary colons in view labels.

4. Remove an explicit `false` check in the `branches` API.

- Primarly whitespace and code style changes.

- Improve feature spec dealing with removing a user from a protected
  branch. Previously, we were only asserting on a "Deleted" flash
  notice. Now the assertion looks at the database to make sure that the
  right access level was removed.

1. Set `gon.current_project_id` in a protected branches controller,
   since that's the only place this is used.

2. Move flash notice to the redirect message.

3. Rename the `js_access_levels` method to `access_levels_options`

4. Scope a `find` while sending a branch protection email.

5. Use scopes to simplify finding users with push/merge access for a
   project.

6. Use `change_column_null`  to avoid an `ActiveRecord::IrreversibleMigration`

- While selecting user access for a protected branch.

-  When a user leaves a project, any access levels that they were
   granted specifically are destroyed.

-  When a user is removed from a project, any access levels that they
   were granted specifically are destroyed.

To work with restricting access to a specific user.

1. While creating a protected branch, you can set a single user / role
  for each setting ("Allowed to Merge", "Allowed to Push").

2. More users / roles can be set subsequently.

3. Repurposed 'users_select.js.coffee` for the needs of this page.

4. Move protected branch settings to the `show` page.

    - Too many settings on the single index page can be overwhelming. Also,
      if the number of users that can access a protected branch is large,
      the amount of space between protected branches in the table can be
      unwieldy.

    - This is the simplest design I can think of - we can use this
      until we have someone from the frontend/ux team take a look at
      this.

    - Move protected branches javascript under a `protected_branches`
      directory.

    - The dropdowns don't show access levels / users that have already been
      selected.

    - Allow deleting access levels using two new access level controllers.

- A protected branch now `has_many` access levels (as opposed to
  `has_one`, which CE will continue to have). Each access level
  represents either a user or a role that is allowed to access the
  protected branch.

- Update `git_access_spec` to test cases where a specific user is given
  access to a protected branch.

- Remove the explicit `push_check` for protected branches. This is
  because a non-developer user (such as a reporter) should be able to
  push code if they are added to a protected branch specifically.

- Fix specs (git_access_spec) that were implicitly depending on a
  master push access level being created (previously, a protected
  branch's default state was "masters can push + masters can merge").
  Since the current default is "none", the dependency needs to be
  explicitly declared.

- Update `git_push_service` so default branch protection (for new repos)
  works as expected.

[ES] Add explanation comments



See merge request !650

Allow LDAP `sync_ssh_keys` setting to be set to `true`

In that case `sync_ssh_keys` will default to the `sshPublicKey` value

Fixes #8

See merge request !670

In that case `sync_ssh_keys` will default to the `sshPublicKey` value.

[ES] Fix for unborn head

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

See merge request !669

Allow syncing a group against all providers at once

## What does this MR do?

Allows `Sync::Group` to sync members for a single group across all providers at once. Closes #399 

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

No

## Why was this MR needed?

The current implementation of LDAP group sync manages members based on a single LDAP provider. This is optimal because we can open a single connection to a given LDAP server (provider) and run all queries needed to sync all GitLab groups with links to that provider. If we want to sync a single group at a time we need to flip that model - for a single group, run the sync for all providers. 

This presents a few challenges since we have a state machine on the group. In the former/current model we need to set the state inside the loop. However, if we do that in the latter model we will likely run into a race condition. At least, it will execute unnecessary queries against the database. Other than adding the functionality needed to sync a single group, the MR moves the state machine handling to the respective class method. 

## What are the relevant issue numbers?

#399

See merge request !636

[ES] Limit amount of retries for sidekiq jobs

ES index data is not that critical and in most of the cases sidekiq jobs fails due to bugs.
What do you think @jnijhof and @pcarranza 

See merge request !666

[ES] Rspec for code that used delete-by-query plugin

We need to reconfigure CI so elastic has `delete-by-query` plugin installed

See merge request !654

Remove tiny grammar mistake

Just removing the "it" at the end of the sentence, I think it was a mistake.

See merge request !667

Refactor description templates documentation

CE https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5839

See merge request !657

Optimize commit and diff changes access check to reduce git operations

Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/880

See merge request !647

Git operations are costly. Before, if file locks and all file locks were
enabled we would iterate over each commit twice and over each diff as much
as 4 times. This updates uses lambdas to go through all neccessary validations
in only one iteration per commit and per diff. It also removes some unused
code in lib/gitlab/git_access.rb and adds examples to ensure the code keeps
working as intended.

CE upstream

@pacoguzman Please resolve `spec/controllers/autocomplete_controller_spec.rb`

See merge request !656

[ES] Record deletion fix

Specs for deletion are in MR https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/654/diffs that is built on top of this MR. I've made it in a separate MR because there is complex stuff left to do. We need another docker image where elastic has plugin `delete-by-query`

No changelog item required because the bug was introduced in master a few days ago by https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/615

See merge request !653