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