This ensures that the vulnerability modal always has an actions
area/footer, even if the vulnerability it's displaying has been resolved
(which can only happen within MRs).

Therefore, this should only have a visual effect on vulnerabilities
fixed within a particular MR, when viewing that MR. The vulnerability
modal is used elsewhere, for instance the Project Security Dashboard,
but in those other places, vulnerabilities can't be "fixed", and so this
should have no effect there.

Before this change, fixed vulnerabilities couldn't be interacted with at
all, since their actions footer wasn't displayed. This meant that the
user could not:
 - dismiss the vulnerability
 - create an issue for the vulnerability
 - create a merge request to fix the vulnerability
 - download a patch to fix the vulnerability

All of these restrictions still make sense, I think. The problem was
that they weren't allowed implicitly before, whereas now they're
disallowed explicitly.

Some more details about the changes:
 - The modal determines what to display based on a handful of `can*`
   props, e.g., `canDismissVulnerability`. These are simply permissions
   about vulnerabilities in general for the current user, and not
   specific to any given vulnerability. Since it's not meaningful to
   dismiss a resolved vulnerability, these permissions have been
   augmented to consider the current status of the vulnerability, via
   the new `can*ThisVulnerability` computed properties.
 - An unused computed prop `renderSolutionCard` was removed. Some test
   code was cleaned up around the `SolutionCard` (preferring finding
   elements via refs and component classes over `js-*` classes).
 - Added/clarified some tests around when and why the modal rendered the
   footer. Previously, permissions were conflated with simply the
   existence of the footer.

See https://gitlab.com/gitlab-org/gitlab/issues/32767.

Increase lower DAG `needs` limit from five to ten

See merge request gitlab-org/gitlab!21237

If the feature flag `ci_dag_limit_needs` is turned on for a GitLab
instance, a job can now depend on up to ten jobs instead of five

Implement and document alpha/beta_feature_available? method

See merge request gitlab-org/gitlab!20840

This adds and documents an `alpha_feature_available?` method to groups
and projects, and also documents the existing `beta_feature_available?`
method.

Add a 'Productivity Improvement.md' issue template

See merge request gitlab-org/gitlab!20794

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

Update the "Edit release" feature's version from 12.5 to 12.6 in the documentation

See merge request gitlab-org/gitlab!21425

Add endpoint for tracking report per person in a given group

See merge request gitlab-org/gitlab!18689

Consider :none as docs only change

Closes #37340

See merge request gitlab-org/gitlab!21144

Fix helm value used for review app default password secret name

Closes #39144

See merge request gitlab-org/gitlab!21469

Resolve "live_debug shouldn't open new page if CHROME_HEADLESS is false"

Closes #22205

See merge request gitlab-org/gitlab!20755

When using CHROME_HEADLESS=0 you can already have a logged-in session on
the page, so no need to open the user's browser as well

Merge branch '38044-qa-scheduled-master-pipeline-failure-notifications-are-not-being-sent-to-slack' into 'master'

Resolve "QA scheduled master pipeline failure notifications are not being sent to Slack"

Closes #38044

See merge request gitlab-org/gitlab!21160

With `allow_failure: true` on a prerequisite job,
when the job fails it would be considered a success.
This results in the `schedule:package-and-qa` job being skipped.

To work around this, we always run
`schedule:package-and-qa:notify-failure`,
and look for a failed `schedule:package-and-qa` in the pipeline.

Surface GitLab issue in error detail page

See merge request gitlab-org/gitlab!21019

Include ee/ in Jest coverage report

See merge request gitlab-org/gitlab!21387

Backend: Create a table for sentry error related issues

See merge request gitlab-org/gitlab!20629

Add table to store the sentry event and issue ids
that are related to a gitlab issue

Fix misaligned approval tr

Closes #38558

See merge request gitlab-org/gitlab!21368

Cleanup styles for Geo Node Items

See merge request gitlab-org/gitlab!21269

Remove unneeded class

Fix geo node status colors

Node warning styles

Cleanup geo-node-item

Cleanup node section items

Mobile friendly node actions

Tweak margins

Remove unneeded class

Starting to fix tests

Another fix

Lots of tests

Final lint and tests

Fix backend tests

Add note on gitlab-managed clusters

See merge request gitlab-org/gitlab!20245

Merge branch '11190-show-most-affected-projects-in-group-security-dashboard-utility-classes' into 'master'

Add text, bg, color and hover utility classes for rendering vulnerability severity levels

See merge request gitlab-org/gitlab!21285

Allow moving forked projects across shards

See merge request gitlab-org/gitlab!21339

Update eslint-plugin-import from 2.16.0 to 2.18.2 (/ee/app/assets/javascripts/analytics)

See merge request gitlab-org/gitlab!17600

Update eslint-plugin-import from 2.16.0 to 2.18.2 (/spec/javascripts/[s-z]*)

See merge request gitlab-org/gitlab!21322

Update eslint-plugin-import from 2.16.0 to 2.18.2 (/app/assets/javascripts/vue_*)

See merge request gitlab-org/gitlab!21461

Update eslint-plugin-import from 2.16.0 to 2.18.2 (/app/assets/javascripts/[p-s]*)

See merge request gitlab-org/gitlab!21358

Remove empty default export

See merge request gitlab-org/gitlab!21433

- Removes empty default export from actions and getters

Update eslint-plugin-import from 2.16.0 to 2.18.2 (/spec/javascripts/[f-i]*)

See merge request gitlab-org/gitlab!21320

Update eslint-plugin-import from 2.16.0 to 2.18.2 (/spec/frontend/[a-l]*)

See merge request gitlab-org/gitlab!21312

Add `--security-remote` flag to bin/secpick

See merge request gitlab-org/gitlab!21274

This specs forking a project that was already the source of a pool
repository after the source project was moved to a different shard.

In this case the old pool repository will continue to exist, containing
all the deduplicated objects from the forks on the first shard. But
we'll create a new PoolRepository for the shart the source project was
moved to.

Then, new forks will be deduplicated using the new PoolRepository on
the new shard.

This allows creating a `PoolRepository` for a source project for each
shard it resides on.