EE: Accept environment variables from the `pre-receive` script

- EE version of gitlab-org/gitlab-ce!7967

See merge request !964

Port of "Add Mattermost Service" to EE

See merge request !972

Update the "remove an estimation" command.

The current documentation is not up to date with the current Gitlab version. 

The current command is `/remove_estimate` to remove estimation time of an issue.

See merge request !970

Don't delete branches/tags that contains changes only in the remote mirror.

Closes #588

See merge request !968

Fix restart link on doc/pages/administration.md

The links for `restart_gitlab.md` and `backup_restore.md` both had an extra `../`, resulting in a `404` on https://docs.gitlab.com/ee/pages/administration.html#nginx-configuration

As mentioned in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/967#note_20134955

See merge request !973

Override LDAP members permissions

This gives owner/master users the ability to override LDAP group synced members permissions. 

LDAP users are given a label to indicate they are a LDAP user. Next to the LDAP user is an edit button which allows the owner/master to change the permissions (with a pre-warning). The owner/master user can also revert this with a new option in the dropdown.

![Screen_Shot_2016-12-09_at_15.33.47](/uploads/ea32bfbf10870abfcac32d533c65c274/Screen_Shot_2016-12-09_at_15.33.47.png)

![Screen_Shot_2016-12-09_at_15.33.50](/uploads/b15ffae6cd939f232698203b1d184877/Screen_Shot_2016-12-09_at_15.33.50.png)

![Screen_Shot_2016-12-09_at_15.33.56](/uploads/d432aa40af75233a7b8d8b0e25e6a8ad/Screen_Shot_2016-12-09_at_15.33.56.png)

Closes #343

See merge request !822

Implement Timetracking v1.1


- [x] Break issuable_time_tracking component into smaller components and bundle them
- [x]  Improve the help state UX to look like this: https://gitlab.com/gitlab-org/gitlab-ee/issues/985#note_16056031
- [x] Create helpers for props existence checking  https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/870#note_18534273
- [x] Standardize on camelCase where possible, improve naming with computed values
- [x] Be clear about using human values from the server vs client 
- [x] Address the accessibility impact of only displaying the remaining time in a tooltip and the percentage of time spent in a colored meter.
- [x] Fix help 'Learn more' URL
- [x] Remove polling until the rest of the sidebar can be synced properly

cc: @jschatz1 

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

See merge request !901

- `raise "string"` raises a `RuntimeError` - no need to be explicit
- Remove top-level comment in the `RevList` class
- Use `%w()` instead of `%w[]`
- Extract an `environment_variables` method to cache `env.slice(*ALLOWED_VARIABLES)`
- Use `start_with?` for env variable validation instead of regex match
- Validation specs for each allowed environment variable were identical. Build them dynamically.
- Minor change to `popen3` expectation.

- Don't define "allowed environment variables" in two places.
- Dispatch to different arities of `Popen.open` without an if/else block.
- Use `described_class` instead of explicitly stating the class name within a
- spec.
- Remove `git_environment_variables_validator_spec` and keep the validation inline.

Previously, we were calling out to `popen` without asserting on the returned
exit-code. Now we raise a `RuntimeError` if the exit code is non-zero.

The list of environment variables in `Gitlab::Git::RevList` need to be validate
to make sure that they don't reference any other project on disk.

This commit mixes in `ActiveModel::Validations` into `Gitlab::Git::RevList`, and
validates that the environment variables are on the level (using a custom
validator class). If the validations fail, the force push is still executed
without any environment variables set.

Add specs for the validation using shared examples.

1. Starting version 2.11, git changed the way the pre-receive flow works.

  - Previously, the new potential objects would be added to the main repo. If the
    pre-receive passes, the new objects stay in the repo but are linked up. If
    the pre-receive fails, the new objects stay orphaned in the repo, and are
    cleaned up during the next `git gc`.

  - In 2.11, the new potential objects are added to a temporary "alternate object
    directory", that git creates for this purpose. If the pre-receive passes, the
    objects from the alternate object directory are migrated to the main repo. If
    the pre-receive fails the alternate object directory is simply deleted.

2. In our workflow, the pre-recieve script (in `gitlab-shell) calls the
   `/allowed` endpoint, which calls out directly to git to perform
   various checks. These direct calls to git do _not_ have the necessary
   environment variables set which allow access to the "alternate object
   directory" (explained above). Therefore these calls to git are not able to
   access any of the new potential objects to be added during this push.

3. We fix this by accepting the relevant environment variables
   (GIT_ALTERNATE_OBJECT_DIRECTORIES, GIT_OBJECT_DIRECTORY) on the
   `/allowed` endpoint, and then include these environment variables while
   calling out to git.

4. This commit includes (whitelisted) these environment variables while making
   the "force push" check. A `Gitlab::Git::RevList` module is extracted to
   prevent `ForcePush` from being littered with these checks.

EE: Resolve "Add a doorkeeper scope suitable for authentication"

- EE counterpart for gitlab-org/gitlab-ce!5951
- Related to gitlab-org/gitlab-ce#20492

See merge request !946

Fix reconfigure link on doc/pages/administration.md

The link had an extra `../` in it and wasn't working on https://docs.gitlab.com/ee/pages/administration.html#nginx-configuration

See merge request !967

The CE merge request renamed the `Oauth2::AccessTokenValidationService` and
converted it from a module to a class. There are two invocations of this
module/class that are EE-only, which needed to be updated.

If we leave this as a regular migration, we could have the following flow:

1. Application knows nothing about scopes.
2. First migration runs, all existing personal access tokens have `api` scope
3. Application still knows nothing about scopes.
4. Second migration runs, all tokens created after this point have no scope
5. Application still knows nothing about scopes.
6. Tokens created at this time _should have the API scope, but instead have no scope_
7. Application code is reloaded, application knows about scopes
8. Tokens created after this point only have no scope if the user deliberately
   chooses to have no scopes.

Point #6 is the problem here. To avoid this, we move the second migration to a
"post" migration, which runs after the application code is deployed/reloaded.

`valid_api_token?` is a better name. Scopes are just (potentially) one facet of
a "valid" token.

- Previously, AccessTokenValidationService was a module, and all its  public
methods accepted a token. It makes sense to convert it to a class which accepts
a token during initialization.

- Also rename the `sufficient_scope?` method to `include_any_scope?`

- Based on feedback from @rymai

- The `scopes_form` partial can be used in the `admin/applications` view
  as well

- Don't allow partials to access instance variables directly. Instead, pass
  in the instance variables as local variables, and use `local_assigns.fetch`
  to assert that the variables are passed in as expected.

- Change a few instances of `render :partial` to `render`

- Remove an instance of `required: false` in a view, since this is the default

- Inline many instances of a local variable (`ip = 'ip'`) in `auth_spec`

Split the existing feature spec into both feature and controller specs.
Feature specs assert on browser DOM, and controller specs assert on database
state.

- Use whitespace to separate the setup, expectation and teardown phases.

- Based on @dbalexandre's review
- Extract token validity conditions into two separate methods, for
  personal access tokens and OAuth tokens.

- The list of scopes that's displayed while creating a personal access
  token is identical to the list that's displayed while creating an OAuth
  application. Extract these into a partial.

- The list of scopes that's displayed while in the show page for an OAuth token
  in the profile settings and admin settings are identical. Extract these into
  a partial.

- Mainly whitespace changes.

- Require the migration adding the `scope` column to the
  `personal_access_tokens` table to have downtime, since API calls will
  fail if the new code is in place, but the migration hasn't run.

- Minor refactoring - load `@scopes` in a `before_action`, since we're
  doing it in three different places.

- This module is used for git-over-http, as well as JWT.

- The only valid scope here is `api`, currently.

- Move the `Oauth2::AccessTokenValidationService` class to
  `AccessTokenValidationService`, since it is now being used for
  personal access token validation as well.

- Each API endpoint declares the scopes it accepts (if any). Currently,
  the top level API module declares the `api` scope, and the `Users` API
  module declares the `read_user` scope (for GET requests).

- Move the `find_user_by_private_token` from the API `Helpers` module to
  the `APIGuard` module, to avoid littering `Helpers` with more
  auth-related methods to support `find_user_by_private_token`