This prevents a MITM attack where attacker could
still access Git repository if any jobs were
running long enough.

This prevents a MITM attack where attacker could
still access Git repository if any jobs were
running long enough.

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

Because we don't have any destroy callbacks (or other logic
triggered on event destroy), there is no reason for deleting events
inefficiently one by one, instead we can use :delete_all.

This change sets NOT NULL constraint to users.private profile.

closes https://gitlab.com/gitlab-org/gitlab-ce/issues/57538

Removed unused method for name setter method

Devise checks before updating any of the authentication_keys if it
needs to clear the reset_password_tokens.

This should fix:
https://gitlab.com/gitlab-org/gitlab-ce/issues/42733 (Weak
authentication and session management)

These are not required because MySQL is not
supported anymore

When a user's notification email is set for a group, we
should use that for pipeline emails

- Background migration for changing null values to false
- Set false as default value for private_profile DB column

Instead of setting the name of the namespace to the user's username,
set it to the user's name.

This is more consistent with how we name the routes:
The route-name of a namespace is the human name of the routable. In
the case of a user-namespace, this is the owner's name.

When we change a user's name (both on create and update), we now also
update the namespace-name to the user's name. This will make sure that
if we also correctly update all the nested routes.

The introduction of the in-memory cache for application settings had a
side effect of making it harder to invalidate changes when the settings
occur. We now bypass the cache because it's possible the admin enabled
the usage ping, and we don't want to annoy the user again if they
already set the value.

To avoid causing significant load on the system, we add an extra check
to ensure the user is an admin. and we don't want to annoy the user
again if they already set the value. This is a bit of hack, but the
alternative would be to put in a more complex cache invalidation
step. Since this call only gets called in the uncommon situation where
the user is an admin and the only user in the instance, this shouldn't
cause too much load on the system.

Disabled password authentication for the users registered using
omniauth-ultraauth strategy