Signed-off-by: Rémy Coutable <remy@rymai.me>

Adds `#build_notification_recipients` to `NotificationRecipientService`
that returns the `NotificationRecipient` objects in order to be able to
access the new attribute `reason`.

This new attribute is used in the different notifier methods in order to
add the reason as a header: `X-GitLab-NotificationReason`.

Only the reason with the most priority gets sent.

[10.3] Prevent login with disabled OAuth providers

See merge request gitlab/gitlabhq!2296

(cherry picked from commit 4936650427ffc88e6ee927aedbb2c724d24b094c)

a0f9d222 Prevents login with disabled OAuth providers

check project access on MR create

See merge request gitlab/gitlabhq!2273

(cherry picked from commit 1fe2325d6ef2bced4c5e97b57691c894f38b2834)

43e85f49 check project access on MR create

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

According to the Chrome source code (https://chromium.googlesource.com/chromium/src/base/+/master/base_switches.cc#120):

The /dev/shm partition is too small in certain VM environments, causing Chrome
to fail or crash (see http://crbug.com/715363). Use this flag to work-around
this issue (a temporary directory will always be used to create anonymous
shared memory files).

Addresses gitlab-org/gitlab-ee#4252 but doesn't appear to cure it completely.

Previously, this would include the entire User record in the update
hash, which was rendered in the response using `to_json`, erroneously
exposing every attribute of that record, including their (now removed)
private token.

Now we only include the user ID, and perform the lookup on-demand.

The ApplicationSetting model uses the CacheMarkdownField concern, which updates
the cached HTML when the field is updated in the database. However, in specs,
when we want to test conditions using ApplicationSetting, we stub it, because
this is accessed in different ways throughout the application.

This means that if a spec runs that caches one of the Markdown fields, and a
later spec uses `stub_application_setting` to set the raw value of that field,
the cached value was still the original one. We can work around this by ignoring
the Markdown cache in contexts where we're using `stub_application_setting`.

We could be smarter, and only do this on the Markdown fields of the model, but
this is probably fine.

By importing this Ruby code into gitlab-rails (and gitaly-ruby), we avoid
200ms of startup time for each gitlab_projects subprocess we are eliminating.

By not having a gitlab_projects subprocess between gitlab-rails / sidekiq and
any git subprocesses (e.g. for fork_project, fetch_remote, etc, calls), we can
also manage these git processes more cleanly, and avoid sending SIGKILL to them

I've followed the [upgrade guide](https://github.com/thoughtbot/factory_bot/blob/4-9-0-stable/UPGRADE_FROM_FACTORY_GIRL.md

) and ran these two commands:

```
grep -e FactoryGirl **/*.rake **/*.rb -s -l | xargs sed -i "" "s|FactoryGirl|FactoryBot|"
grep -e factory_girl **/*.rake **/*.rb -s -l | xargs sed -i "" "s|factory_girl|factory_bot|"
```

Signed-off-by: Rémy Coutable <remy@rymai.me>

Moving the check out of the general requests, makes sure we don't have
any slowdown in the regular requests.

To keep the process performing this checks small, the check is still
performed inside a unicorn. But that is called from a process running
on the same server.

Because the checks are now done outside normal request, we can have a
simpler failure strategy:

The check is now performed in the background every
`circuitbreaker_check_interval`. Failures are logged in redis. The
failures are reset when the check succeeds. Per check we will try
`circuitbreaker_access_retries` times within
`circuitbreaker_storage_timeout` seconds.

When the number of failures exceeds
`circuitbreaker_failure_count_threshold`, we will block access to the
storage.

After `failure_reset_time` of no checks, we will clear the stored
failures. This could happen when the process that performs the checks
is not running.

Later migrations added fields to the EE DB which were used by factories which were used in these specs.

And in CE on MySQL, a single appearance row is enforced.

The migration and migration specs should not depend on the codebase staying the same.

This throttles the number of UPDATE queries that can be triggered by
calling "touch" on a Note, Issue, or MergeRequest. For Note objects we
also take care of updating the associated "noteable" relation in a
smarter way than Rails does by default.

* Hopefully fixes spec failures in which the table doesn’t exist
* Decouples the background migration from the post-deploy migration, e.g. we could easily run it again even though the table is dropped when finished.