This makes it easier to query, simplifies the code, and makes it
possible to figure out what transaction the data belongs to (simply
because it's now stored _in_ the transaction).

This new setup keeps track of both the real/wall time _and_ CPU time
spent in a block, both measured using milliseconds (to keep all units
the same).

This allows us to track how much time of a transaction is spent in
dealing with cached data.

This changes the timestamp of metrics to be more accurate/unique by
using Time#to_f combined with a small random jitter value. This
combination hopefully reduces the amount of collisions, though there's
no way to fully prevent any from occurring.

Fixes gitlab-com/operations#175

Fix error that was causing only one group to be returned and corrected specs to use the proper attribute type

This reverts commit 7f287c91.

This allows measuring of timings of arbitrary Ruby blocks, this allows
for more fine grained performance monitoring. Custom values and tags can
also be attached to a block.

This fixes the problem where Markdown such as:

    ### 31st

Would get rendered as a link tag pointing to issue number 31 inside a
header tag.

See gitlab-org/gitlab-ce#14936 for more information.

not_found appends string "Not Found" to the argument causing the resulting message to be "Branch does not exist Not Found" which is an incorrect error message.

Changed the argument of not_found! for 'unprotect'  command to "Branch" from "Branch does not exist".  This makes the final error message to appear as "Branch Not Found" which is correct and same as error messages for other commands like 'protect'.

Changed config syntax and  improved how chaanges in group memberships are handled when external groups is set up

Resolves #14411.

See merge request !3464

Cleaning this up any further is a bit tricky as the caches in question
should only be evaluated if RequestStore is actually enabled.

Every object processed by ExternalIssueReferenceFilter can return a
different Project instance when calling "project". For example, every
note processed will have it's own associated Project. If we were to
cache Project#default_issues_tracker? on Project level this would have
no impact on Markdown rendering timings as the cache would have to be
built for every Project instance without it ever being re-used.

To work around this we cache Project#default_issues_tracker? in
Banzai::Filter::ExternalIssueReferenceFilter using the project's _id_
instead of the whole object. This setup allows re-using of the cached
data even when the Project instances used are different, as long as the
actual project IDs are the same.

For an issue with around 200 notes this cuts down timings by around 150
milliseconds.

These methods always return the same data for every class so there's no
point in computing their values on every call.

These filters now use a single iteration over all the document nodes
instead of multiple ones. This in turn allows variables to be re-used
(e.g. links only have to be unescaped once). Combined with some other
refactoring this can drastically reduce render timings.

This was originally suggested by @ayufan and modified to be a bit
cleaner and use RequestStore instead of a regular Hash.

By caching the output of the two methods involved the number of queries
is reduced significantly. For example, for an issue with 200 notes (of
which 100 reference a number of merge requests) this cuts down the
amount of queries from around 6300 to around 3300.

Rails' "url_helpers" method creates an anonymous Module (which a bunch
of methods) on every call. By caching the output of this method in a
dedicated method we can shave off about 10 seconds of loading time for
an issue with around 200 comments.

I’ve removed everything related to the feature based on this commit:
ce08f919f34fd8849834365

Resolves #10857.

Also, streamline the view.
Signed-off-by: NRémy Coutable <remy@rymai.me>

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

By pre-calculating the digests we can manually construct the emoji URLs,
removing the need for using Rails' asset URL helpers. The reason we
don't want to use these helpers for Emojis is two-fold:

1. Rails' image_url() method is slow, really slow. For one it _might_
   have to calculate digests but it also performs a lot of other
   intensive operations (judging by the source code and based on
   measuring timings).

2. We have a lot of Emoji which coupled with the above can result in it
   taking minutes to load Emoji autocomplete data.

Using this pre-calculation setup generating the digests takes around 7
seconds (including the time it takes to start Rails/Rake), and only
around 600 milliseconds to load _all_ the autocomplete data of a project
(measured locally).

This commit _does_ change the Emoji URLs from absolute to relative URLs
as these are much easier to generate.

To update the Emoji data simply run:

    rake gemojione:digests

Then commit any changes.

Fixes gitlab-org/gitlab-ce#14009