Add RequestCache to cache via RequestStore

See merge request !12920

Protect manual actions against protected tag too

Closes #34927

See merge request !12908

Perf: Improve performance of basic ruby ops in DeclarativePolicy

See merge request !12922

fix transient rspec failure due to Poll.js race condition

Closes #35225

See merge request !12930

Renamed Gitaly services

Closes gitaly#379

See merge request !12854

Update 9.3-to-9.4.md

See merge request !12925

don't treat aborted requests as failures, they are often triggered during unload (e.g after clicking a link)

Refactor variables initialization in dropzone_input.js

Closes #29901

See merge request !12768

Remove coffee-rails gem

Closes #34831

See merge request !12715

fix padding on filtered search

Closes #35177

See merge request !12913

We also try to use instance variable to cache the result if
RequestStore is not available, so we could keep the same logic,
using the same cache key. Also introduce a way to specify method
specific cache key

Resolve "Peek performance bar doesn't count cached queries, but shows them"

Closes #34940

See merge request !12915

Resolve "Don't let webhooks jobs go to the dead jobs queue"

Closes #31571

See merge request !12918

Added sub-nav to new group sidebar settings

Closes #35140

See merge request !12907

These jobs may legitimately fail because the endpoint just isn't there any
more. We don't want them cluttering up the Sidekiq morgue in that case - it's
currently full on GitLab.com.

Fixed project members link not staying active

Closes gitlab-ee#2942

See merge request !12882

I don't like the idea of `RequestStore` at all, because it's just a
global state which shouldn't be used at all. But we have a number of
places calling `ProtectedBranch.protected?` and `ProtectedTag.protected?`
in a loop for the same user, project, and ref whenever we're checking
against if the jobs for a given pipeline is accessible for a given user.
This means we're effectively making N queries for the same thing over
and over.

To properly fix this, we need to change how we check the permission,
and that could be a huge work. To solve this quickly, adding a cache
layer for the given request would be quite simple to do.

We're already doing this in Commit#author, and this is extending that
idea and make it generalized.

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

Promote visibility level helpers from Group to Namespace

Closes gitlab-ee#2950

See merge request !12910

move click handler to button. when on the icon it wasn't triggered in firefox

Closes #35164

See merge request !12905

Process scheduled background migrations as well

Closes #34951

See merge request !12787

Expire cached user IDs that can see the performance after 5 minutes

See merge request !12911

Simply re-raise an exception when it occurs, but guarantee that no
background migration is lost in the process.

Added cop to blacklist the use of hash indexes

See merge request !12869

If we don't expire the cached user IDs, the list of IDs would become
outdated when a new member is added, or when a member ios removed from
the allowed group.
Signed-off-by: Rémy Coutable <remy@rymai.me>

Remove Repository#search_files

See merge request !12879