Re-organize schema. Drop protected from runner. Add access_level to runner. Drop protected from pipeline. Add protected to ci_bilds.

Solution 1. Persists protected(ref) flag on ci_pipelines table. builds_for_shared_runner and builds_for_specific_runner read the flag instead of executing protected_for? one by one.

Issue discussions Vue refactor

See merge request !12069

Ensure `issuables_count_for_state` returns the requested state count

Closes #37353

See merge request !14005

We were incorrectly stubbing `Issues::MoveService#execute`. This only
caused a failure when another spec caused it to be autoloaded --
`spec/controllers/projects/issues_controller_spec.rb` in this case.

Add settings for minimum key strength and allowed key type

Closes #17849

See merge request !13712

Remove issuable finder count caching

See merge request !13959

Make pipeline dropdowns consistent

See merge request !13530

Reduce duration and complexity of spec/features/issues/filtered_search/filter_issues_spec.rb

See merge request !13973

Optimize notification emails specs

See merge request !13986

Fixes the fly-out navigation flashing in & out

Closes #37022

See merge request !13929

The assignee wasn't important to the test, and shortening the query
allowed us to avoid the "horizontal scroll" failure without having to
stub the `sidebar_collapsed?` helper.

We now document that fact.

We were essentially testing "all of the filters" four times, so now we
just do it once at the top level.

Three issues were only used in one test each, and one milestone with its
accompanying issue were only used in one test, so we now scope those
locally.

Removes unnecessary `let!` usage since we explicitly access these in the
`before.

Re-uses `user2` as the author for issues we otherwise don't care about
the author for, to avoid creating a new user in each one.

Makes use of the `labeled_issue` factory to avoid assigning variables
just so we can add labels to an issue.

This seemed to only exist to increment an issue counter by 1.

Only one context tested group behavior, but we were performing group and
membership creation on every example unnecessarily.

While testing the various search tokens, we would add the token and a
search term, then verify the correct issues were returned. Then we'd add
a new token, search again, and verify again. Then another, and another.

This was entirely redundant. If the search with higher specificity
returned the same results as the search with lower specificity, we can
be sure the lower specificity searches also worked without actually
testing them.

Because this entire spec performs very extensive setup, it's important
to limit the number of times we perform that setup.