Fix RSpec/EmptyLineAfterFinalLetItBe for ee/spec/services/ci

See merge request gitlab-org/gitlab!58354

Fix RSpec/EmptyLineAfterFinalLetItBe for ee/spec/policies

See merge request gitlab-org/gitlab!58371

Subscription Details: add Subscription Breakdown View

See merge request gitlab-org/gitlab!58760

Update initial branch name in commit specs

See merge request gitlab-org/gitlab!58878

Fix EmptyLineAfterFinalLetItBe offenses in spec/graphql/types

See merge request gitlab-org/gitlab!58241

Update Gitaly version

See merge request gitlab-org/gitlab!59140

Remove str-truncated-60 class from common.scss

See merge request gitlab-org/gitlab!58210

Externalize strings in services/index.html.haml

See merge request gitlab-org/gitlab!58167

Fail batch-aborted pipelines with reason

See merge request gitlab-org/gitlab!57838

Immediately unlink potentially-large temporary files

See merge request gitlab-org/gitlab!57239

Updated the initial branch name from master to main

Fix typo in Frontend GraphQL development guide

See merge request gitlab-org/gitlab!59099

Update api jobs to fix sort order detail

See merge request gitlab-org/gitlab!59090

Clarify that build_timeout is in seconds

See merge request gitlab-org/gitlab!59025

Update feature category of some actions/endpoints

See merge request gitlab-org/gitlab!56841

Secure Go development docs: Test Fixture guidance

See merge request gitlab-org/gitlab!57752

Fix changelog from !57952

See merge request gitlab-org/gitlab!59089

Include project and build ID in Pages tmp directory

See merge request gitlab-org/gitlab!59106

Add search functionality to Jira Connect App namespaces

See merge request gitlab-org/gitlab!57669

Puma has a limit (`Puma::Const::MAX_BODY` - around 110 KiB) over which
it will write request bodies to disk for handing off to the
application. When it does this, the request body can be left on disk
if the Puma process receives SIGKILL. Consider an extremely minimal
`config.ru`:

    run(proc { [204, {}, []] })

If we then:

1. Start `puma`, noting the process ID.
2. Start a slow file transfer, using `curl --limit-rate 100k` (for
   example) and `-T $PATH_TO_LARGE_FILE`.
3. Watch `$TMPDIR/puma*`.

We will see Puma start to write this temporary file. If we then send
SIGKILL to Puma, the file won't be cleaned up. With this patch, it
will.

The patch itself is pretty unpleasant: as Puma has two quite long
methods that set up the temporary files (`Puma::Client#setup_body` and
`Puma::Client#setup_chunked_body`), we have to copy those methods and
call `#unlink` in the correct spots in both. Also, as these are private
methods, it's hard to write a test for them. We can test manually.
Running `fswatch -t -x $TMPDIR | grep puma` while posting a large file
shows this with this patch:

    Fri Mar 26 20:34:10 2021 ... Created Removed IsFile
    Fri Mar 26 20:34:21 2021 ... Updated IsFile

Whereas without this patch we get:

    Fri Mar 26 20:32:57 2021 ... Created IsFile
    Fri Mar 26 20:33:05 2021 ... Created Removed Updated IsFile

Rack writes files from multipart/form-data requests to disk in a
temporary file. Rack includes a middleware to clean these up -
Rack::TempfileReaper - but that won't withstand a process being sent
SIGKILL. To handle that case, we can immediately unlink the created
temporary file, which means it will be removed once we're done with it
or the current process goes away.

For development mode and test mode, we have to ensure that this new
middleware is before Gitlab::Middleware::Static, otherwise we might not
get the chance to set our own middleware.

With direct upload configured, GitLab mostly doesn't accept
multipart/form-data requests in a way where they reach Rack directly -
they typically go via Workhorse which accelerates them - but there are
cases where it can happen, and direct upload is still only an option.

To test this manually, we can set `$GITLAB_API_TOKEN_LOCAL` to a
personal access token for the API in the local environment,
`$PATH_TO_FILE` to be a path to a (preferably large) file to be
uploaded, and break the actual saving of uploads (in the default case
with GDK, stop Minio):

    curl -H "Private-Token: $GITLAB_API_TOKEN_LOCAL" \
      -F "file=@$PATH_TO_FILE" \
      http://localhost:3000/api/v4/projects/1/uploads

Once the upload is finished and the request fails, we'll see the file we
uploaded in `$TMPDIR`:

    $ ls -l $TMPDIR/RackMultipart* | awk '{ print $5, $8 }'
    952107008 17:40

With this change, that won't happen: we'll see the file created and
immediately unlinked, so no matter what happens, it won't stick around
on disk. (This specific test case is handled by Rack::TempfileReaper in
later versions of Rack, but it still depends on manual cleanup.)

Merge branch '325263-wiki-kerberos-clone-button-fails-with-undefined-local-variable-or-method-project' into 'master'

Fix 500 error when cloning a wiki using the Kerberos clone button

See merge request gitlab-org/gitlab!58270

These actions/endpoints are not under code review feature category.

They're are under the following categories:
- `code_testing`
- `usability_testing`
- `continuous_integration`

Fix EmptyLineAfterFinalLetItBe offenses in spec/services/groups

See merge request gitlab-org/gitlab!58423

Migrate delete label modal to Vue

See merge request gitlab-org/gitlab!58131

Update default branch in divergence graph

See merge request gitlab-org/gitlab!58871

Change to "read-write" rather than "read write" in database_spec.rb

See merge request gitlab-org/gitlab!59067

Merge branch '247515-the-ssh-key-page-at-profile-keys-should-mention-that-expired-keys-only-cause-warnings-and' into 'master'

The SSH Key page should mention that expired keys only cause warnings and will continue working

See merge request gitlab-org/gitlab!57494