We had concerns about the cached values on Redis with the previous two
releases strategy:

First release (this commit):
  - Create new encrypted fields in the database.
  - Start populating new encrypted fields, read the encrypted fields or
    fallback to the plaintext fields.
  - Backfill the data removing the plaintext fields to the encrypted
    fields.
Second release:
  - Remove the virtual attribute (created in step 2).
  - Drop plaintext columns from the database (empty columns after
    step 3).

We end up with a better strategy only using migration scripts in one
release:
  - Pre-deployment migration: Add columns required for storing encrypted
    values.
  - Pre-deployment migration: Store the encrypted values in the new
    columns.
  - Post-deployment migration: Remove the old unencrypted columns

This is the plan to encrypt the plaintext tokens:

First release (this commit):
  1. Create new encrypted fields in the database.
  2. Start populating new encrypted fields, read the encrypted fields or
     fallback to the plaintext fields.
  3. Backfill the data removing the plaintext fields to the encrypted fields.

Second release:
  4. Remove the virtual attribute (created in step 2).
  5. Drop plaintext columns from the database (empty columns after step 3).

- A regular migration caused problems such as
https://gitlab.com/charts/gitlab/issues/1565.

The Sidekiq job `RemoveExpiredMembersWorker` was failing to run in
production because it was hitting statement timeouts because it was
scanning all rows in order. On staging, where it used to scan 4 million
rows, adding an index brought this down to only a few hundred rows.

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

Notes on epics promoted from an issue used to get same discussion_id
as the notes from the issue the epic was promoted from, which would
cause problems when trying to reply to the epic discussion.

This fixes previously added migration which caused timeouts on
big events table.

It consists of two parts:

1. Redirecting users to the configured external storage
1. Allowing the external storage to request the static object(s)
   on behalf of the user by means of specific tokens

Part of https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/6829

On our dev instance, /admin/applications as not loading because:

1. There was an unindexed query by `application_id`.
2. There was an expensive query that attempted to load 1 million
   unique entries via ActiveRecord just to find the unique count.

We fix the first issue by adding an index for that column.

We fix the second issue with a simple SELECT COUNT(DISTINCT
resource_owner_id) SQL query.

In addition, we add pagination to avoid loading more than 20
applications at once.

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

Detect if pipeline runs for a GitHub pull request

When using a mirror for CI/CD only we register a pull_request
webhook. When a pull_request webhook is received, if the
source branch SHA matches the actual head of the branch in the
repository we create immediately a new pipeline for the
external pull request. Otherwise we store the
pull request info for when the push webhook is received.

When using "only/except: external_pull_requests" we can detect
if the pipeline has a open pull request on GitHub and create or
not the job based on that.

Since it is not possible to dynamically detect if a job is automatically
cancellable or not, a this new attribute is necessary. Moreover, it let
the maintainer of the repo to adjust the behaviour of the auto cancellation
feature to match exactly what he needs.

These are the structural changes for supporting the EE feature of moving
"code_owner_approval_required" state from existing on a project to being
on the protected branches individually, allowing for CODEOWNER
validation on push events.

This speeds up the following query:

```sql
SELECT  users.* FROM users WHERE users.unconfirmed_email = ? ORDER BY
users.id ASC LIMIT 1
```

Presumably, this is a query coming from Devise.

Context is https://gitlab.com/gitlab-org/gitlab-ce/issues/66958.

If someone installed EE, then downgraded to CE before this column was
added, upgrading to the latest version of CE will fail:

1. We have a backport migration for the entire EE schema but the table
   `epic_issues` exists, just not the `relative_position` column.
2. The migration that changes the default (quite reasonably) didn't
   check if the column exists.

If the column doesn't exist, we can just create it with the correct
default.

This creates a partial index intended to speed up queries on
`ci_builds`. Particularly, `gitlab-monitor` has rather heavy queries.
Those have been changed to only look back 7 days and benefit from this
index tremendously.

Relates to
https://gitlab.com/gitlab-org/gitlab-exporter/merge_requests/101.

Creates new event when an epic is created, closed, reopened or
commented.