- Break vue component into smaller components and bundle them
 - Improve the help state UX to look like this: #985 (comment 16056031)
 - Create helpers for props existence checking !870 (comment 18534273)
 - Standardize on camelCase where possible, improve naming with computed values
 - Be clear about using human values from the server vs client
 - Consider & address the accessibility impact of only displaying the remaining
  time in a tooltip and the percentage of time spent in a colored meter.
 - Fix help 'Learn more' URLAppend state computed values with 'State'.

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

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