We can simplify the code quite a bit and improve performance by using
grape-entity merge fields:

https://github.com/ruby-grape/grape-entity/tree/v0.6.0#merge-fields

Relates to #42030

This reverts merge request !16626

To make it more clear to developers that the entity exposes the
application secret, define a separate entity that only should be used
when the secret is needed (probably only on creation).

[10.3] Migrate `can_push` column from `keys` to `deploy_keys_project`

See merge request gitlab/gitlabhq!2276

(cherry picked from commit f6ca52d31bac350a23938e0aebf717c767b4710c)

1f2bd3c0 Backport to 10.3

Merge branch 'security-10-3-do-not-expose-passwords-or-tokens-in-service-integrations-api' into 'security-10-3'

Filter out sensitive fields from the project services API

See merge request gitlab/gitlabhq!2281

(cherry picked from commit 476f2576444632f2a9a61b4cead9c1077f2c81d7)

2bcbbda0 Filter out sensitive fields from the project services API

This removes all usage of soft removals except for the "pending delete"
system implemented for projects. This in turn simplifies all the query
plans of the models that used soft removals. Since we don't really use
soft removals for anything useful there's no point in keeping it around.

This _does_ mean that hard removals of issues (which only admins can do
if I'm not mistaken) can influence the "iid" values, but that code is
broken to begin with. More on this (and how to fix it) can be found in
https://gitlab.com/gitlab-org/gitlab-ce/issues/31114.

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

+ Add support for the new separate channel and events settings
* Dry up chat notifications in the service properties definitions

[10.2] Ensure we expose group projects using GroupProjectsFinder

See merge request gitlab/gitlabhq!2234

(cherry picked from commit 072f8f2fd6ec794645375a16ca4ddc1cbeb76d7a)

a2240338 Ensure we expose group projects using GroupProjectsFinder

Fix https://gitlab.com/gitlab-org/gitlab-ce/issues/40825

Two things at ones, as there was no clean way to seperate the commit and
give me feedback from the tests.

But the model Artifact is now JobArtifact, and the table does not have a
type anymore, but the metadata is now its own model:
Ci::JobArtifactMetadata.

To allow jobs/builds to have multiple artifacts, and to start seperating
concerns from Ci::Build a new model is created: Ci::Artifact.

Changes include the updating of the ArtifactUploader to adapt to a
slightly different interface. The uploader expects to be initialized
with a `Ci::Build`.

Futher a migration with the minimal fields, the needed foreign keys and
an index.

Last, the way this works is by prepending a module to Ci::Build so we
can basically override behaviour but if needed use `super` to get the
original behaviour.