Disable all unnecessary Sidekiq-cron workers when node is a Geo secondary

See merge request !2261

Port of issueable-list-cleanup to EE

See merge request !2262

[EE] Allow the feature flags to be enabled/disabled with more granularity

See merge request !2290

[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

Most of the workers need to update the database, which fails
miserably on the secondary.

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.

Locally, if Spring was not restarted, `current_application_settings` was still cached, which prevented the migration from editing the file. This will also ensure that any app server somehow hitting old cache data will properly default this setting regardless.