Merge branch '325413-dark-mode-light-colored-branch-indicator-badges-are-hard-to-read' into 'master'

Fix badges and border in info wells in dark mode

See merge request gitlab-org/gitlab!58875

Add OncallScheduleEntity with data to members

See merge request gitlab-org/gitlab!58848

Add N+1 query specs for the snippet index actions

See merge request gitlab-org/gitlab!58732

Enable Layout/SpaceInsideArrayLiteralBrackets cop for HAML

See merge request gitlab-org/gitlab!59143

Add setting to change default MR target project

See merge request gitlab-org/gitlab!58093

Add a new index to improve query performance

See merge request gitlab-org/gitlab!58895

Skip Rack Attack rate limiting for container registry event API

See merge request gitlab-org/gitlab!59085

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

As seen in https://gitlab.com/gitlab-org/gitlab/-/issues/327416,
previously Rack Attack throttled
`/api/v4/container_registry_event/events`, which then caused Rack Attack
to rate limit on other unauthenticated requests, such as fetches to
remote CI YAML files.

Since this is a trusted request from the Docker API, we can exempt this
from our rate limiting. We now skip the request if the path starts with
`/api/v4/container_registry_event/`.  We now skip the request if the
path starts with `/api/v4/container_registry_event/`.

Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/327416

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

Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>

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.)