Upgrade danger and add roulette [EXPERIMENT]

What does this MR do?

• Introduce the reviewer roulette to our Danger Bot.
• Do some CI/CD code cleanup as the Danger Bot imported. We're changing to including the shared https://gitlab.com/gitlab-org/quality/pipeline-common/-/blob/master/ci/danger-review.yml as recommended by the Danger bot docs, instead of manually configuring the Danger job and pulling the registry.gitlab.com/gitlab-org/gitlab-build-images:danger. The Danger Bot is installed via the gitlab-dangerfiles gem that we're installing in the before_script.

Availability control

By default, the roulette will try to randomize the distribution of MRs for reviewers to review, with the same weight for each reviewer. Although, each reviewer can control how their chances of being picked will be considered in this game. This is useful when reviewers want to reduce/increase/block their income of review requests.

The roulette controls a reviewer/maintainer availability based on our statuses on GitLab.com or Slack. There is a set of recognized emojis that one can use to completely block the roulette from picking you, adding a specific limit of maximum reviews that you'd like be taking care at any time, or even tell the roulette that you want to get more reviews as usual as possible.

See https://docs.gitlab.com/ee/development/code_review.html#reviewer-roulette

Reviewer status check

When the roulette prints a orange exclamation mark ❗ besides the name, instead of the green check ✅, it means that the reviewer which was available by the time of the suggestion when danger ran, is not available anymore. This can happen if a reviewer was available back then, but then went OOO afterwards, or changed their status to one of the busy statuses. If the reviewer is already reviewing the MR, this can be disregarded. If the Author still want to find a reviewer, they can re-run the danger bot, so that the reviewer roulette will try suggest someone different.

Categorizing reviewers per scope

We haven't introduced categorization to gitlab-org/charts roulette yet. But the roulette is capable of detecting different scoped reviewers, then suggesting one reviewer/maintainer for each scope. I would do this on a follow-up though, so we can start simpler.

E.g., docs::maintainer, maintainer, reviewer, trainee maintainer and even custom categories like reviewer::kas (only illustrative, can become reviewer::ci for instance).

Related issues

Propose Reviewer Roulette experiment for Chart ... (gitlab-org/distribution/team-tasks#1304 - closed)

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

• Merge Request Title and Description are up to date, accurate, and descriptive
• MR targeting the appropriate branch
• MR has a green pipeline on GitLab.com
• When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes
• Documentation created/updated
• Tests added
• Integration tests added to GitLab QA
• Equivalent MR/issue for omnibus-gitlab opened
• Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme://user:passwd@host:port may require quotation or other special handling when rendered in a template and written to a configuration file.