Closes #19398

Removing unused access_level parameter.

Bug introduced here -> 6d103a2f
access_level parameter wasn’t needed since -> 88c26393

* Works by explicitly deleting out-of-date data attributes

* No longer directly assigns to data-original-title

Outlook seems to handle `white-space: pre` weirdly, so just use `pre`
elements (but only for emails!).

* Only the first 10 names are displayed

* Further users are indicated by "and X more."

* String "and X more" is appended to the array THEN join is called

* An oxford comma seperates the last name from "and X more"

* In coffeescript "me" is now always prepended

* Tests included

GitLab Performance Monitoring is now able to track custom events not
directly related to application performance. These events include the
number of tags pushed, repositories created, builds registered, etc.

The use of these events is to get a better overview of how a GitLab
instance is used and how that may affect performance. For example, a
large number of Git pushes may have a negative impact on the underlying
storage engine.

Events are stored in the "events" measurement and are not prefixed with
"rails_" or "sidekiq_", this makes it easier to query events with the
same name triggered from different parts of the application. All events
being stored in the same measurement also makes it easier to downsample
data.

Currently the following events are tracked:

* Creating repositories
* Removing repositories
* Changing the default branch of a repository
* Pushing a new tag
* Removing an existing tag
* Pushing a commit (along with the branch being pushed to)
* Pushing a new branch
* Removing an existing branch
* Importing a repository (along with the URL we're importing)
* Forking a repository (along with the source/target path)
* CI builds registered (and when no build could be found)
* CI builds being updated
* Rails and Sidekiq exceptions

Fixes gitlab-org/gitlab-ce#13720

Use just SQL to check is a user can admin_issue on a project

Tradeoff

- we duplicate how we check admin_issue in a SQL relation in the Ability class

[ci skip]

This ensures that SVGs greater than 2 megabytes are not scrubbed and
rendered. This in turn prevents requests from timing out due to
reading/scrubbing large SVGs potentially taking a lot of time (and
memory). The use of 2 megabytes is completely arbitrary.

Fixes gitlab-org/gitlab-ce#1435

Closes #20828

Currently when a user performs an update of a file through the UI  and there
has already been a change committed to the file the previous commits will be
overwritten without a check to see if the file has been changed.

This commit uses the last commit sha at the time the user starts editing the
file and compares it with the current sha of the file being edited to ensure
they are the same before committing the file. If the shas do not match we
throw an exception preventing the commit from the commit from occurring.

Fixes #5857

In Banzai::Filter::SanitizationFilter#customize_whitelist, we append
three lambdas that has reference to the SanitizationFilter instance,
which in turn (potentially) has a reference to the following chain:

context hash -> Project instance -> Repository instance -> lookup hash
-> various Rugged instances -> various mmap-ed git pack files.

All of the above is not garbage collected because the array we append
the lambdas to is the constant
HTML::Pipeline::SanitizationFilter::WHITELIST.