as we destroy all gpg_signatures we don't need to downcase the email
addresses anymore.

This is faster for the deployment process, as the destroyed signatures
will be re-generated on demand again, instead of updating them all on
deploy.

To avoid having to implement legacy code handling for the obsolete
`verified_signature` attribute and to avoid any race conditions during
the zero-downtime-deployment we do the following:

1. Destroy all records
2. Migration: Use add_column_with_default to add the new attribute and
   update the verification_status values on records created between 1.
   and 2.
3. Deploy the new code
4. Post migration: Destroy all records

Like this we make sure that at no point there is a record with a `nil`
value for the new `verification_status` attribute.

Remove access_level index from runner. Add protected on ci_pipelines. Add protected index on ci_builds.

Re-organize schema. Drop protected from runner. Add access_level to runner. Drop protected from pipeline. Add protected to ci_bilds.

Solution 1. Persists protected(ref) flag on ci_pipelines table. builds_for_shared_runner and builds_for_specific_runner read the flag instead of executing protected_for? one by one.

`allowed_key_types` is removed and the `minimum_<type>_bits` fields are
renamed to `<tech>_key_restriction`. A special sentinel value (`-1`) signifies
that the key type is disabled.

This also feeds through to the UI - checkboxes per key type are out, inline
selection of "forbidden" and "allowed" (i.e., no restrictions) are in.

As with the previous model, unknown key types are disallowed, even if the
underlying ssh daemon happens to support them. The defaults have also been
changed from the lowest known bit size to "no restriction". So if someone
does happen to have a 768-bit RSA key, it will continue to work on upgrade, at
least until the administrator restricts them.

This is an amalgamation of:

* Cory Hinshaw: Initial implementation !5552
* Rémy Coutable: Updates !9350
* Nick Thomas: Resolve conflicts and add ED25519 support !13712

This column isn't always set (e.g. when upgrading from older instances)
and technically it could be NULL (e.g. when flushing the cache).

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36919

There might be some projects where the namespace was removed, but the
project wasn't. For these the projects still have a `namespace_id`
set. So this adds a post-deploy migration remove all projects that are
pending delete, and have a `namespace_id` that is non-existing.

Using `extend` dynamically can lead to bad performance as it
invalidates the method's cache.