This is no longer needed with Rails 5.2. opclass is the attribute used
per https://github.com/rails/rails/pull/19090/files.

Now that we've removed the monkey patch and restored the Rails schema
dumper, it appears Rails has dropped the inclusion of `using: :btree` as
well (https://github.com/rails/rails/pull/27981).

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/64529

and state

Adds migration to introduce non-regular rule_types to
approval_project_rules

- Set access level in before_validation hook
- Add post migration for updating existing project_features

- Background migration for changing null values to false
- Set false as default value for private_profile DB column

This eliminates conflicts between CE and EE db/schema.rb files.

This makes the CE and EE tables consistent and ensures changes in the
schema for the CE version don't cause conflicts with EE.

Updates changed method names and fixes spec failures

When GitLab was migrating to Gitaly, feature flags were used. These are
now out of use, and essentially a no-op. But they do make the output of
chatops ugly and the feature table is selected in full by the
application.

This MR introduces tracking of the `rebase_jid` for merge requests. As
with `merge_ongoing?`, `rebase_in_progress?` will now return true if a
rebase is proceeding in sidekiq.

After one release, we should remove the Gitaly-based lookup of rebases.
It is much better to track this kind of thing via the database.

Add released_at field to releases API
Add released_at column to releases table
Return releases to the API sorted by released_at

This new attribute is optional and used when set instead of the default
format `gitlab+deploy-token-#{id}`.

Empty usernames will be saved as null in the database.

Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/50228.

- Migration updates existing groups to "owner", then sets default to
  "maintainer" so that new groups will default to that
- Update spec examples

- instead of using properties
- backward compatibility has to be kept for now

- Migration updates existing groups to "owner", then sets default to
  "maintainer" so that new groups will default to that
- Update spec examples

- Migration updates existing groups to "owner", then sets default to
  "maintainer" so that new groups will default to that
- Update spec examples

We nullify when cluster is deleted as we want to keep the deployment
record around.

Add cluster as an optional association

We will have only cluster for deployments where the build deploys to a
kubernetes cluster

- Namespace::Storagestatistics will persist root namespace statistics
- Namespace::AggregationSchedule will save information when a new update
to the namespace statistics needs to be scheduled

Both tables use 'namespace_id' as primary key

This reverts commit 51340f9b47e8339cdabce11d0a17ac724278bff0.

Changes migration and all other places the attribute is used

Adds an instance setting to limit display of time tracking
values to hours only

Add index for pages domain ssl auto renewal
Add PagesDomain.needs_ssl_renewal scope
Add cron worker for ssl renewal
Add worker for ssl renewal
Add pages ssl renewal worker queues settings

Adds enum certificate_source to pages_domains table
with default manually_uploaded

Mark certificates as 'gitlab_provided'
if the were obtained through Let's Encrypt

Mark certificates as 'user_provided' if they were uploaded through
controller or api

Only show private key in domain edit form if it is 'user_provided'

Only show LetsEncrypt option if is enabled by application settings
(and feature flag)

Refactor and fix some specs to match new logic

Don't show Let's Encrypt certificates as well

This couples the code that transitions the `MergeRequest#merge_status`
and refs/merge-requests/:iid/merge ref update.

In general, instead of directly telling `MergeToRefService` to update
the merge ref, we should rely on `MergeabilityCheckService` to keep
both the merge status and merge ref synced. Now, if the merge_status is
`can_be_merged` it means the merge-ref is also updated to the latest.

We've also updated the logic to be more systematic and less user-based.

In https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21497, we
migrated all project import data into a separate table,
`project_import_data`.  In addition, we also added:

```
ignore_column :import_status, :import_jid, :import_error
```

In https://gitlab.com/gitlab-com/gl-infra/production/issues/908, we
observed some of these `import_error` columns consumed megabytes of
error backtraces and caused slow loading of projects whenever a `SELECT
* from projects` query loaded the row into memory.

Since we have long migrated away from these columns, we can now drop
these columns entirely.

Bringing in the DB migration and some light changes for CE classes