Using the sed script from
https://gitlab.com/gitlab-org/gitlab-ce/issues/59758

Mixing and matching the use of Rack::Request and ActionDispatch::Request
in Rails 5 is bad, particularly if you have middleware that
manipulates or accesses environment variables.

`Gitlab::Middleware::Multipart` attempts to rewrite request parameters
to the proper values (e.g. replacing `data_file` with
`UploadedFile`). It does this by calling `Rack::Request#update_params`,
which essentially updates `env['rack.request.form_hash']`.

By changing to `ActionDispatch::Request`, the Go middleware was causing
the request parameters to be stored inside
`env['action_dispatch.request.request_parameters']`. Later calls to
`Rack::Request#update_params` would not have any effect because it would
attempt to update `env['rack.request.form_has']` instead of
`env['action_dispatch.request.request_parameters']`. As a result, the
controller still saw the old parameters.

Since the Go middleware appears to be using `ActionDispatch::Request`
for authorization methods, we can switch the multipart middleware to
use it too.

Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/9035

When direct_upload is enabled and a for file is being uploaded,
then workhorse uses `public/uploads/tmp` path. If `uploads.storage_path`
i sset to a different directory, then upload fails because
`public/uploads/tmp` is not in allowed paths.

In the attempt to unify file uploading at workhorse level gitlab-org/gitlab-workhorse!230
we moved to a prefix-based tempfile creation in order to avoid upload collisions.

Artifacts and LFS uploads already set original_filename to workhorse provided filename

This commit add the same feature to `Gitlab::Middleware::Multipart`

I mistakenly concluded Rack::Multipart injects File instances into the
params. These should be UploadedFile instances. This reuses a mock
UploadedFile class we already had in GitLab.

Ruby 2.1 requires a basename argument to `Tempfile.open`, so just call
it something that makes sense in context for the spec.