These are the structural changes for supporting the EE feature of moving
"code_owner_approval_required" state from existing on a project to being
on the protected branches individually, allowing for CODEOWNER
validation on push events.

This commit includes changes to add `UserAccess#can_create_branch?`
which will check whether the user is allowed to create a branch even
if it matches a protected branch.

This is used in `Gitlab::Checks::BranchCheck` when the branch name
matches a protected branch.

A `push_to_create_protected_branch` ability in `ProjectPolicy` has been
added to allow Developers and above to create protected branches.

Determined by running the script:

```
included = `git grep --name-only ShellAdapter`.chomp.split("\n")
used = `git grep --name-only gitlab_shell`.chomp.split("\n")
included - used
```

Partially addresses #47424.

When checking if a branch is protected we don't need all columns of
every protected branch row, instead we only care about the names. By
using "select" here we reduce the amount of data we need to send over
the wire and load into memory.

The initializers including this were doing so at the top level, so every object
loaded after them had a `current_application_settings` method. However, if
someone had rack-attack enabled (which was loaded before these initializers), it
would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't
have that method.

To fix this:

1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need
   `Object.new.current_application_settings` to work.
2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it
   like that in several places.
3. Change the initializers to use that new form.

Improvements and refactorings were made while adding role based permissions for protected tags to EE. This doesn’t backport the feature, but should improve code quality and minimize divergence.

This memorized array appears to originally come from https://gitlab.com/gitlab-org/gitlab-ee/commit/19c2c90ccac86a21eb4266b9a5972162f917f692 which has a commit message of ‘fix warnings’. Without any comments on the original pull request I think we can safely get rid of it unless warnings re-appear.

Should provide basic CRUD backend for frontend to work from. Doesn’t include frontend, API, or the internal API used from gitlab-shell

!581 has a lot of changes that would cause merge conflicts if not
properly backported to CE. This commit/MR serves as a better
foundation for gitlab-org/gitlab-ee!581.

= Changes =

1. Move from `has_one {merge,push}_access_level` to `has_many`, with the
   `length` of the association limited to `1`. This is _effectively_ a
   `has_one` association, but should cause less conflicts with EE, which
   is set to `has_many`. This has a number of related changes in the
   views, specs, and factories.

2. Make `gon` variable loading more consistent (with EE!581) in the
   `ProtectedBranchesController`. Also use `::` to prefix the
   `ProtectedBranches` services, because this is required in EE.

3. Extract a `ProtectedBranchAccess` concern from the two access level
   models. This concern only has a single `humanize` method here, but
   will have more methods in EE.

4. Add `form_errors` to the protected branches creation form. This is
   not strictly required for EE compatibility, but was an oversight
   nonetheless.

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. 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. 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. The `open_branches` method is used to provide a list of branches
   while creating a protected branch.

2. It makes sense to include branches which are matched by one or more
   wildcard protected branches, since the user might want to make exact
   protected branches from these as well.

3. This also provides a large performance improvement. On my machine, in
   a project with 5000 branches and 2000 protected branches, the
   `ProtectedBranches#index` page went from a 40 seconds load time to 4
   seconds (10x speedup).

1. Allow entering any branch name for a protected branch.

    - Either pick from a list of options, or enter it manually
    - You can enter wildcards.

2. Display branches matching a protected branch.

    -  Add a `ProtectedBranches#show` page that displays the branches
       matching the given protected branch, or a message if there are no
       matches.

    - On the `index` page, display the last commit for an exact match,
      or the number of matching branches for a wildcard match.

    -  Add an `iid` column to `protected_branches` - this is what we use for
       the `show` page URL.

    -  On the off chance that this feature is unnecessary, this commit
       encapsulates it neatly, so it can be removed without affecting
       anything else.

3. Remove the "Last Commit" column from the list of protected branches.

    - There's no way to pull these for wildcard protected branches, so it's
      best left for the `show` page.

    - Rename the `@branches` instance variable to `@protected_branches`

    - Minor styling changes with the "Unprotect" button - floated right
      like the "Revoke" button for personal access tokens

4. Paginate the list of protected branches.

5. Move the instructions to the left side of the page.

1. The main implementation is in the `ProtectedBranch` model. The
   wildcard is converted to a Regex and compared. This has been tested
   thoroughly.

    - While `Project#protected_branch?` is the main entry point,
      `project#open_branches` and
      `project#developers_can_push_to_protected_branch?`
      have also been modified to work with wildcard protected branches.

    - The regex is memoized (within the `ProtectedBranch` instance)

2. Improve the performance of `Project#protected_branch?`

    -  This method is called from `Project#open_branches` once _per branch_
       in the project, to check if that branch is protected or not.

    -  Before, `#protected_branch?` was making a database call every
       time it was invoked (in the above case, that amounts to once
       per branch), which is expensive.

    -  This commit caches the list of protected branches in memory, which
       reduces the number of database calls down to 1.

    -  A downside to this approach is that `#protected_branch?` _could_
       return a stale value (due to the caching), but this is
       an acceptable tradeoff.

3. Remove the (now) unused `Project#protected_branch_names` method.

    - This was previously used to check for protected branch status.

This reverts commit 3e991230.

# Conflicts:
#	app/models/project.rb

In 8278b763 the default behaviour of annotation
has changes, which was causing a lot of noise in diffs. We decided in #17382
that it is better to get rid of the whole annotate gem, and instead let people
look at schema.rb for the columns in a table.

Fixes: #17382

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>