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

since they can't log in

to make sure we mean the global permissions

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

Since we will likely be needing this for other features, for example the
Gitlab ServiceDesk support bot.

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

- Add a `destroy_user` ability. This didn't exist before, and was implicit in
  other abilities (only admins could access the admin area, so only they could
  destroy all users; a user can only access their own account page, and so can
  destroy only themselves).

- Grant this ability to admins, and when the current user is trying to destroy
  themselves. Disallow destroying ghost users in all cases.

- Modify the `Users::DestroyService` to check this ability. Also check it in
  views to decide whether or not to show the "Delete User" button.

- Add a short summary of the Ghost User to the bio.

- Have `Uniquify` take a block instead of a Proc/function. This is more
  idiomatic than passing around a function in Ruby.

- Block a user before moving their issues to the ghost user. This avoids a data
  race where an issue is created after the issues are migrated to the ghost user,
  and before the destroy takes place.

- No need to migrate issues (to the ghost user) in a transaction, because
  we're using `update_all`

- Other minor changes

1. Refactoring and specs in the `Uniquify` class.

2. Don't use the `AdvisoryLocking` class. Similar functionality is
provided (backed by Redis) in the `ExclusiveLease` class.

Rather than using a separate `ghost` state. This lets us have the benefits of
both ghost and blocked users (ghost: true, state: blocked) without having to
rewrite a number of queries to include cases for `state: ghost`.

1. Use an advisory lock to guarantee the absence of concurrency in `User.ghost`,
to prevent data races from creating more than one ghost, or preventing the
creation of ghost users by causing validation errors.

2. Use `update_all` instead of updating issues one-by-one.

1. Create a `Uniquify` class, which generalizes the process of generating unique
   strings, by accepting a function that defines what "uniqueness" means in a
   given context.

2. WIP: Make sure tests for `Namespace` pass, add more if necessary.

3. WIP: Add tests for `Uniquify`

- "Associated" issues are issues the user has created + issues that the
  user is assigned to.

- Issues that a user owns are transferred to a "Ghost User" (just a
  regular user with `state = 'ghost'` that is created when
  `User.ghost` is called).

- Issues that a user is assigned to are moved to the "Unassigned" state.

- Fix a spec failure in `profile_spec` — a spec was asserting that when a user
  is deleted, `User.count` decreases by 1. After this change, deleting a user
  creates (potentially) a ghost user, causing `User.count` not to change. The
  spec has been updated to look for the relevant user in the assertion.

This reverts commit cb10b725c8929b8b4460f89c9d96c773af39ba6b.

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

Fixes #25279

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

Adding changelog entry

This column used to be a 32 bits integer, allowing for only a maximum of
2 147 483 647 rows. Given enough users one can hit this limit pretty
quickly, as was the case for GitLab.com.

Changing this type to bigint (= 64 bits) would give us more space, but
we'd eventually hit the same limit given enough users and projects. A
much more sustainable solution is to simply drop the "id" column.

There were only 2 lines of code depending on this column being present,
and neither truly required it to be present. Instead the code now uses
the "project_id" column combined with the "user_id" column. This means
that instead of something like this:

    DELETE FROM project_authorizations
    WHERE user_id = X
    AND id = Y;

We now run the following when removing rows:

    DELETE FROM project_authorizations
    WHERE user_id = X
    AND project_id = Y;

Since both user_id and project_id are indexed this should not slow down
the DELETE query.

This commit also removes the "dependent: destroy" clause from the
"project_authorizations" relation in the User and Project models.
Keeping this prevents Rails from being able to remove data as it relies
on an "id" column being present. Since the "project_authorizations"
table has proper foreign keys set up (with cascading removals) we don't
need to depend on any Rails logic.