This MR adds a string (thus max 255 chars) field to the enviroments
table to expose it later in other features.

1. Instantiate `ProtectedBranchesAccessSelect` from `dispatcher`

2. Use `can?(user, ...)` instead of `user.can?(...)`

3. Add `DOWNTIME` notes to all migrations added in !5081.

4. Add an explicit `down` method for migrations removing the
   `developers_can_push` and `developers_can_merge` columns, ensuring that
   the columns created (on rollback) have the appropriate defaults.

5. Remove duplicate CHANGELOG entries.

6. Blank lines after guard clauses.

1. It makes sense to reuse these constants since we had them duplicated
   in the previous enum implementation. This also simplifies our
   `check_access` implementation, because we can use
   `project.team.max_member_access` directly.

2. Use `accepts_nested_attributes_for` to create push/merge access
   levels. This was a bit fiddly to set up, but this simplifies our code
   by quite a large amount. We can even get rid of
   `ProtectedBranches::BaseService`.

3. Move API handling back into the API (previously in
   `ProtectedBranches::BaseService#translate_api_params`.

4. The protected branch services now return a `ProtectedBranch` rather
   than `true/false`.

5. Run `load_protected_branches` on-demand in the `create` action, to
   prevent it being called unneccessarily.

6. "Masters" is pre-selected as the default option for "Allowed to Push"
   and "Allowed to Merge".

7. These changes were based on a review from @rymai in !5081.

1. Remove `master_or_greater?` and `developer_or_greater?` in favor of
   `max_member_access`, which is a lot nicer.

2. Remove a number of instances of `include Gitlab::Database::MigrationHelpers`
   in migrations that don't need this module. Also remove comments where
   not necessary.

3. Remove duplicate entry in CHANGELOG.

4. Move `ProtectedBranchAccessSelect` from Coffeescript to ES6.

5. Split the `set_access_levels!` method in two - one each for `merge` and
   `push` access levels.

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]

[ci skip]

Users can filter branches by name on project branches page

This MR aims to solve #18674 by adding the possibility to filter project branches by name

![Screen_Shot_2016-07-07_at_17.21.25](/uploads/b674765d2b1cb8a121c2101715a4568b/Screen_Shot_2016-07-07_at_17.21.25.png)

See merge request !5144