We should be asking the mime type method for the mime objects rather
than via const lookup

all parameter parsing is done on the request object now, so we don't
need to worry about at ParamParser middleware

The test request object will handle parsing XML posts now, so we don't
need to eagerly parse them in the test harness

The request object will automatically parse these in the
`parse_formatted_parameters` method, so we don't have to worry about it.

In c546a2b0 this was changed to mimic how the browser behaves in a real
situation but left out types that were registered.

When this was changed it didn't take `text/plain` or `text/html` content
types into account. This is a problem if you're manipulating the
`Content-Type` headers in your controller tests, and expect a certain
result.

The reason I changed this to use `to_sym` is because if the
`Content-Type` is not registered then the symbol will not exist. If it's
one of the special types we handle that specifically (:json, :xml, or
:url_encoded_form). If it's any registered type we handle it by setting
the `path_parameters` and then the `request_parameters`. If the `to_sym`
returns nil an error will be thrown.

If the controller test sets a `Content-Type` on the request that `Content-Type`
should remain in the header and pass along the filename.

For example:
If a test sets a content type on a post
```
@request.headers['CONTENT_TYPE'] = 'text/plain'
post :create, params: { name: 'foo.txt' }
```

Then `foo.txt` should be in the `request_parameters` and params related
to the path should be in the `path_parameters` and the `Content-Type`
header should match the one set in the `@request`. When c546a2b0 was
committed `text/plain` and `text/html` types were throwing a "Unknown
Content-Type" error which is misleading and incorrect.

Note: this does not affect how this is handled in the browser, just how
the controller tests handle setting `Content-Type`.

Just include the modules necessary in the Request object to implement
the things we need.  This should make it easier to build delegate
request objects because the API is smaller

With changes made in 8363b8 and ae291421 cookies that are mutated on the
request like `cookies.signed = x` were not retained in subsequent tests,
breaking cookie authentiation in controller tests.

The test added demonstrates the issue.

The reason we need to select from non-deleted cookies is because without
checking the `@delete_cookies` the `cookie_jar` `@cookies` will send the
wrong cookies to be updated. The code must check for `@deleted_cookies`
before sending an `#update` with the requests cookie_jar cookies.
This follows how the cookie_jar cookies from the request were updated
before these changes.

The following Rails code failed (with a `KeyError` exception) under
test:

```ruby
class ApplicationController < ActionController::Base
  def user_strategy
    # At this point:
    # ```ruby
    # session == {
    #   "user_strategy"=>"email",
    #   "user_identifying_value"=>"hello@world.com"
    # }
    # ```
    if session.key?(:user_strategy)
      session.fetch(:user_strategy)
    end
  end
end
```

When I checked the session's keys (`session.keys`), I got an array of
strings. If I accessed `session[:user_strategy]` I got the expected
`'email'` value. However if I used `session.fetch(:user_strategy)` I
got a `KeyError` exception.

This appears to be a Rails 4.2.4 regression (as the code works under
Rails 4.2.3).

Closes #21383

superclass already has this method, so remove this one

This is part of a larger refactoring on controller tests. We needed to
move these methods here so that we could get rid of the `|| key ==
:action || key == :controller` in `assign_parameters`. We know this is
ugly and intend to fix it but for now `generate_extras` needs to be used
in the two methods to access the path and the query_string_keys.

We're adding `:controller` and `:action` to the `query_string_keys`
because we always need a controller and action. If someone passed
`action` or `controller` in in there test they are unambigious - we
know they have to go into the query params.

`extra_keys` is a confusing variable name because it's not clear what is
"extra". This renames it to `query_string_keys` so it's clear that the
"extra" is just the query string.

allow testing controllers that use session#fetch with a default value.

Rack [already implements `redirect?` on the response object](https://github.com/rack/rack/blob/1569a985e17d9caaf94d0e97d95ef642c4ab14ba/lib/rack/response.rb#L141) so we don't need to implement our own.

ActionController::TestResponse was removed in d9fe10cb and caused a test
failure on Action View as its test case still refers to it.

PATH_INFO is already set, so this branch will never execute.

we were already generating a path in the previous code (it was just not
returned), so lets just use the already computed path to popluate the
PATH_INFO header

Since we only work with new instances, these ivars will not be set.

We should call the setter on `path_parameters` so that we know the hash
will only contain the values that we've set.

I'd like to put all env mutations together so we can understand how to
change this code to call `call` on the controller

Since parameters are converted to a query string, they will
automatically be turned in to strings by the query parser

non_path_parameters is used internally (it never escapes this method) so
we should be able to safely use a regular hash.

since we are serializing parameters, we don't need to do all the dup
checks on each object.

We should roundtrip the parameters through their respective encoders /
decoders so that the controller will get parameters similar to what they
actually get in a real world situation

We should convert request parameters to a query string, then let the
request object parse that query string.  This should give us results
that are more similar to the real-world

We should assign parameters to the request object rather than mutate the
hash that is returned by `query_parameters` or `request_parameters`

this prevents mutations from being available globally

Instead of trying to manually clear out a request object, lets just
allocate a new one.  The rack ENV is reused and cleaned (still), but the
request object is not.