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.

In 0d5df6f0 (repository: Implement `#new_blobs` via `#list_blobs`,
2021-08-25), we have introduced an alternative implementation of
`#new_blobs` which uses `ListBlobs()` instead of `ListNewBlobs()`. While
there wasn't yet any change in behaviour, this conversion allows us to
convert `#new_blobs` to receive multiple new revisions as arguments such
that we can batch-load new blobs in a single call instead of having to
do so once per change.

Remove the feature flag that has been guarding this new implementation
such that we can continue with the conversion. While the new code has
only been tested in production for one day at the time of writing this
commit, there haven't been any issues. Furthermore, the risk of this
change was low from the beginning. So removing the feature flag this
quickly shouldn't be much of a concern.

Changelog: added

Drop Markdown support in bio field

See merge request gitlab-org/gitlab!68628

This is a follow-up to
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69622.

In dismiss_button.vue, the __() call was removed, since the argument
is already in a translated form via s__().

In modal_footer.vue, the __() call was removed, since the argument
is already in a translated form via s__().

In minutes_usage_project_chart.vue, the GlSprintf component was removed,
since it was effectively a no-op as it had no slots provided. The actual
rule violation has not been fixed, as it requires a bit more work to
solve correctly.

Clean up group_level_protected_environments feature flag

See merge request gitlab-org/gitlab!69272

Mention limitations to error tracking

See merge request gitlab-org/gitlab!69641

Release diffs_batch cached rendering

See merge request gitlab-org/gitlab!69617

Resolve "Improve MigrationHelpers to support the PK migration - STEP 3"

See merge request gitlab-org/gitlab!68849

Update dependency @gitlab/ui to v32.7.1

See merge request gitlab-org/gitlab!69552

Update prepare_async_index migration helper to avoid subtransaction

See merge request gitlab-org/gitlab!69262

Fix 'New merge request' button

See merge request gitlab-org/gitlab!69437

Ensure VSA form submits only required fields

See merge request gitlab-org/gitlab!69630

Move Project-level VSA record filtering into FOSS

See merge request gitlab-org/gitlab!69197

Update Gitaly version

See merge request gitlab-org/gitlab!69637

Document update process for the GitLab.com for Jira Cloud app

See merge request gitlab-org/gitlab!69399

Allow tick_for callsite

See merge request gitlab-org/gitlab!69623