Also removes `Thread.current[:current_user]` assignment from
`gitlab_sign_in_via`

This was mistakenly added in 17196a2f and is identical to the group
above it.

[EE] Split up MergeRequestsController

See merge request !2295

Integration/refactor declarative policy

See merge request !2286

Update schema with `datetime_with_timezone` type

See merge request !2297

Use gl_repository exclusively as identifier on post-receive

See merge request !2288

Related Issues UI Polish

Closes #2756

See merge request !2268

Default `authorized_keys_enabled` setting to true

Closes #2738

See merge request !2240

Remove prop because it no longer contains "related issue" in it
and probably doesn't need to be customized anymore

See https://gitlab.com/gitlab-org/gitlab-ce/issues/34336

See https://gitlab.com/gitlab-org/gitlab-ce/issues/34336

See https://gitlab.com/gitlab-org/gitlab-ce/issues/34336

See https://gitlab.com/gitlab-org/gitlab-ce/issues/34336

See https://gitlab.com/gitlab-org/gitlab-ce/issues/34336

See https://gitlab.com/gitlab-org/gitlab-ce/issues/34336

Geo - Fix log message when trying to sync a project with invalid id

Closes #2784

See merge request !2294

Clarify the expiration date of PATs

See merge request !2198

Do the work synchronously to avoid multiple workers attempting to add batches of keys at the same time.

Also, make the delete portion wait until after adding is done.

Reminder: The original migration was fixed retroactively a few commits ago, so people who did not ever run GitLab 9.3.0 already have a column that defaults to true and disallows nulls. I have tested on PostgreSQL and MySQL that it is safe to run this migration regardless.

Affected customers who did run 9.3.0 are the ones who need this migration to fix the authorized_keys_enabled column.

The reason for the retroactive fix plus this migration is that it allows us to run a migration in between to fix the authorized_keys file only for those who ran 9.3.0.