This commit is to abstract the code away from the env hash.  It no
longer needs to have the routes key hard coded.

This changes the renderer class to store the controller and defaults as
an instance variable rather than allocating a new class.  You can create
a new renderer with an new env by calling `Renderer#new` or use new
defaults by calling `Renderer#with_defaults` and saving the return value
somewhere.

Also I want to keep the `env` private since I would like to change the
keys in the future.  This commit only translates particular keys that
the user requested.

this means the reader doesn't need to lock, but does have the added cost
of a new object created for every controller

The controller class is shared among threads, so we need to lock when
allocating the Renderer.

AC::Parameters does not inherit from HashWithIndifferentAccess
since #20868 by @sikachu

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

everything above metal really doesn't care about setting the content
type, so lets rearrange these methods to be in metal.

_set_content_type only does something when there is a request object,
otherwise the return value of _get_content_type is always ignored. This
commit moves everything to the module that has access to the request
object so we'll never to_s unless there is a reason

in the future I would like to make the header hash read only (or at
least remove guarantees that mutations will do anything).

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

typo "description not clear corrected with proper description and action_controller_overview file Rails' ->  Rails" [ci skip]

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.

References #19565.

* A string in the example lacked quotes.

* The tests asserted stuff about :last_name, whereas
  test params do not have that key.

* But, the first one passed, why? After hitting my head against
  the wall and doing some obscure rituals realized the new
  #require had an important typo, wanted to iterate over the
  array argument (key), but it ran over its own hash keys
  (method #keys).

* Modified the test to prevent the same typo to happen again.

* The second test assigned to an unused variable safe_params
  that has been therefore removed.

* Grammar of the second test description.

* Since I was on it, reworded both test descriptions.

This PR adds ability to accept arrays which allows you to require multiple values in one method. so instead of this:

```ruby
params.require(:person).require(:first_name)
params.require(:person).require(:last_name)
```

Here it will be one line for each params, so say if I require 10params, it will be 10lines of repeated code which is not dry. So I have added new method which does this in one line:

```ruby
params.require(:person).require([:first_name, :last_name])
```

Comments welcome

This reverts commit cae2b5bb.

I am an idiot.

Apparently the AbstractController (whatever "abstract" means) is
expected to work without a request and response.

`render` is the only possible source for the `plain` option.  Pulling
the conditional up to the `render` method removes far away conditionals

We don't need to pass the full hash just to pull one value out.  It's
better to just pass the value that the method needs to know about so
that we can abstract it away from "options"

Since all controller instances are required to have a request and
response object, RackDelegation is no longer needed (we always have to
delegate to the response)

the subclass sets the body on the response object, so we don't need the
superclass doing it too

without this module, the content type is not set correctly

Now that `Controller#status=` just delegates to the response object,
we don't need to set the response on the controller and the response.
We can just set it in one place.

we always have a response object, so there is no reason to test it

these ivars don't exist anymore, so we can remove them from the list

since the controller always has a request on it, we can just ask the
request for the content type.

The controller instance always has an instance of a response object.  We
should store the status code on the response object so that it's only
store in one place.

We always have a response object in controller instances, so we can
remove this conditional

controller instances always have a response object, so we don't need to
test to see if there is one, just always call to_a on the response.

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

Controllers should always have a request and response when responding.
Since we make this The Rule(tm), then controllers don't need to be
somewhere in limbo between "asking a response object for a rack
response" or "I, myself contain a rack response".  This duality leads to
conditionals spread through the codebase that we can delete:

  * https://github.com/rails/rails/blob/85a78d9358aa728298cd020cdc842b55c16f9549/actionpack/lib/action_controller/metal.rb#L221-L223