Object store for artifacts

Closes gitlab-ce#29203

See merge request !1762

Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

This finishes the procedure for migrating events from the old format
into the new format. Code no longer uses the old setup and the database
tables used during the migration process are swapped, with the old table
being dropped.

While the database migration can be reversed this will 1) take a lot of
time as data has to be coped around 2) won't restore data in the
"events.data" column as we have no way of restoring this.

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

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.

Given the user can soon have multiple config sources for CI, we now store
what type at the time of the pipeline run we chose. This will give us
insight into what triggered the new pipeline so we can display it to the
enduser.

Behind an application setting, which defaults to false, this commit
implements the implied CI/CD config. Which means that in the case we
can't find the `.gitlab-ci.yml` on the commit we want to start a
pipeline for, we fall back to an implied configuration.

For now the Bash template has been copied to
`Auto-Devops.gitlab-ci.yml` so the tests actually work.

Fixes #34777

`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

Due to a missing `on_delete: :cascade`, users would hit the error that
looked like:

```
PG::ForeignKeyViolation: ERROR: update or delete on table "protected_tags"
violates foreign key constraint "fk_rails_f7dfda8c51" on table
"protected_tag_create_access_levels" DETAIL: Key (id)=(1385) is still
referenced from table "protected_tag_create_access_levels". : DELETE FROM
"protected_tags" WHERE "protected_tags"."id" = 1385
```

Closes #36013