When an issuable's state changes, or one is created, we should clear the cache
counts for a user's assigned issuables, and also the project-wide caches for
this user type.

We were including controller params in the cache key, so the key for the header
didn't match the one for the list itself!

These cache a hash of counts by state, so the state isn't needed in the key
itself.

Add a foreign key to `merge_requests.head_pipeline_id`

Closes #34065

See merge request !12837

Resolve "Test/Production environment imparity in nokogiri"

Closes #34915

See merge request !12842

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>