Updates the vuex store to remove the legacy
'daysInPast' state key that was used to track
the number of days to search across.

With the newer project VSA endpoints we can safely
filter only using `createdBefore` and `createdAfter`
parameters.

Minor refactor utils and fix store specs

Updates the vuex store action and mutation
specs to remove the daysInPast state key.

Adds a filter bar to project VSA to support
filtering at the project level

Update related jest specs

Adds updated specs for the cycle analytics filter
bar in project level VSA.

Changelog: added

Make user deactivation emails opt-in

See merge request gitlab-org/gitlab!68089

Release cached merge_request show.json

See merge request gitlab-org/gitlab!69618

Allow callsite for merge request view

See merge request gitlab-org/gitlab!69596

Improve UI text for Maintenance Mode

See merge request gitlab-org/gitlab!69264

Refactor ZoomValidator to use `gitlab/zoom_url` namespace

See merge request gitlab-org/gitlab!69650

Doc Consistency: api/u...

See merge request gitlab-org/gitlab!69698

Add a warning about PAT auth ignoring username

See merge request gitlab-org/gitlab!68463

Remove name parameter from pipeline finder

See merge request gitlab-org/gitlab!68997

Docs: workaround lack of multiple value variables

See merge request gitlab-org/gitlab!69148

Fix profiles of Romanian proofreaders

See merge request gitlab-org/gitlab!69703

Fix fetch iteration cadence by id

See merge request gitlab-org/gitlab!67083

Unify CommitStatus preloaders

See merge request gitlab-org/gitlab!69477

We have a few places where we preload relations for commit status
objects. Ci::Build, Ci::Bridge and GenericCommitStatus have different
relations, so we have conditions where we preload them.

In this commit, we are unifying this logic.

Global Search - Header Search Refactor Init

See merge request gitlab-org/gitlab!68681

[docs] Resolve "Improve cluster management project (and template) documentation"

See merge request gitlab-org/gitlab!68475

Update the 1Password item where Review App password can be found

See merge request gitlab-org/gitlab!69657

Update Gitaly version

See merge request gitlab-org/gitlab!69659

docs: fix milestones date fields in API responses

See merge request gitlab-org/gitlab!69614

New page with alpha/beta support definitions from handbook

See merge request gitlab-org/gitlab!67718

GitLab hasn't verified the object storage options

See merge request gitlab-org/gitlab!69619

push_rules: Implement bulk-checking of file sizes

See merge request gitlab-org/gitlab!69449

Use 'has been revoked' instead of 'no longer valid'

See merge request gitlab-org/gitlab!69525

Skip archiving job traces after five failed attempts

See merge request gitlab-org/gitlab!68285

Address vue i18n literal string violations

See merge request gitlab-org/gitlab!69621

Make milestone required in metric definition

See merge request gitlab-org/gitlab!69638

The file size check checks each newly pushed blob's size to see whether
it's bigger than a configured threshold and, if so, rejects the ref
update. This is an expensive check though: we need to go both through
all preexisting as well as all new refs in order to find out new blobs
via a graph walk. As such, this check doesn't only scale with the number
of changes, but also with the repository size itself.

Now that `#new_blobs` knows to handle multiple new revisions at once in
a single RPC call to Gitaly, we can convert this check to use a single
bulk-load of new blobs. While this doesn't help much with walking the
positive side of the graph walk, it does amortize the negative walk of
all preexisting refs and will thus in most cases result in a significant
speedup if multiple changes are to be checked.

Ideally, we'd go even further and enumerate new blobs directly via the
quarantine directory: we wouldn't have to do a graph walk at all in this
case, but can just directly look up all new blobs. While this would be
as fast as we can get, the downside is that we wouldn't have blob paths
available anymore given that these blobs wouldn't have been walked via a
tree object. We would still be able to at least present the blob ID to
the user, but the user experience is definitely worse in this case.

We may still at a later point decide to go this step given that it si a
huge performance win (e.g. on gitlab-org/gitlab, we're talking about
10ms vs 30s). But for now, this commit only does the uncontroversial
part of batch-computing new blobs.

Changelog: performance

Let `#new_blobs` accept multiple new revisions such that it's possible
to compute new blobs across multiple changes instead of having to load
blobs per changed ref.