This reverts commit 3420a145, reversing
changes made to afb66a5a.

".. with __dir__ we can restore order in the Universe." - by @fxn

Related to 5b8738c2

```
go get -u github.com/client9/misspell/cmd/misspell
misspell  -w -error -source=text .
```

Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces

Fix all violations in the repository.

The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.

When a `respond_to` collector doesn't have a response, then a
`:no_content` response should be rendered. This brings the default
rendering behavior introduced by
https://github.com/rails/rails/issues/19036 to controller methods
employing `respond_to`

1. Conceptually revert #20276

   The feature was implemented for the `responders` gem. In the end,
   they did not need that feature, and have found a better fix (see
   plataformatec/responders#131).

   `ImplicitRender` is the place where Rails specifies our default
   policies for the case where the user did not explicitly tell us
   what to render, essentially describing a set of heuristics. If
   the gem (or the user) knows exactly what they want, they could
   just perform the correct `render` to avoid falling through to
   here, as `responders` did (the user called `respond_with`).

   Reverting the patch allows us to avoid exploding the complexity
   and defining “the fallback for a fallback” policies.

2. `respond_to` and templates are considered exhaustive enumerations

   If the user specified a list of formats/variants in a `respond_to`
   block, anything that is not explicitly included should result
   in an `UnknownFormat` error (which is then caught upstream to
   mean “406 Not Acceptable” by default). This is already how it
   works before this commit.

   Same goes for templates – if the user defined a set of templates
   (usually in the file system), that set is now considered exhaustive,
   which means that “missing” templates are considered `UnknownFormat`
   errors (406).

3. To keep API endpoints simple, the implicit render behavior for
   actions with no templates defined at all (regardless of formats,
   locales, variants, etc) are defaulted to “204 No Content”. This
   is a strictly narrower version of the feature landed in #19036 and
   #19377.

4. To avoid confusion when interacting in the browser, these actions
   will raise an `UnknownFormat` error for “interactive” requests
   instead. (The precise definition of “interactive” requests might
   change – the spirit here is to give helpful messages and avoid
   confusions.)

Closes #20666, #23062, #23077, #23564

[Godfrey Chan, Jon Moss, Kasper Timm Hansen, Mike Clark, Matthew Draper]

Rails 4.x and earlier didn't support `Mime::Type[:FOO]`, so libraries
that support multiple Rails versions would've had to feature-detect
whether to use `Mime::Type[:FOO]` or `Mime::FOO`.

`Mime[:foo]` has been around for ages to look up registered MIME types
by symbol / extension, though, so libraries and plugins can safely
switch to that without breaking backward- or forward-compatibility.

Note: `Mime::ALL` isn't a real MIME type and isn't registered for lookup
by type or extension, so it's not available as `Mime[:all]`. We use it
internally as a wildcard for `respond_to` negotiation. If you use this
internal constant, continue to reference it with `Mime::ALL`.

Ref. efc6dd55

This will silence deprecation warnings.

Most of the test can be changed from `render :text` to render `:plain`
or `render :body` right away. However, there are some tests that needed
to be fixed by hand as they actually assert the default Content-Type
returned from `render :body`.

Variants are typically set in the controller based on some attribute of
the request that the browser sent.  We should make our tests more in
line with reality by doing the same and not mutating the request object.

In 0de4a23d the behavior when there is a missing template was changed to
not raise an error, but instead head :no_content.  This is a breaking
change and some gems rely on this happening.

To allow gems and other code to work around this, allow
`default_render` to take a block which, if provided, will
execute the contents of that block instead of doing the `head :no_content`.

After merging #19377 ActionPack tests were missing a require for
`ActiveSupport::LogSubscriber::TestHelper` and change didn't take
into account that logger could be nil. Added the require and only log to
info if logger exists.

This wasn't caught earlier because these tests only run after a merge.

in `ActionController::TestCase` and
`ActionDispatch::Integration`

Old syntax:

    `xhr :get, :create, params: { id: 1 }`

New syntax example:

    `get :create, params: { id: 1 }, xhr: true`

Non-kwargs requests are deprecated now.
Guides are updated as well.

`post url, nil, nil, { a: 'b' }` doesn't make sense.
`post url, params: { y: x }, session: { a: 'b' }` would be an explicit way to do the same

This functionality has been extracted to the responders gem.

respond_with (and consequently the class-level respond_to)
are being removed from Rails. Instead of moving it to a 3rd
library, the functionality will be moved to responders gem
(at github.com/plataformatec/responders) which already provides
some responders extensions.

Adds a comment before JSONP callbacks. See
http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/ for more
details on the exploit in question.

The controller can set the response format as 'JSON' before the renderer code be
evaluated, so we must replace it when necessary.

Fixes #15081

When requesting a controller with the following code with a unknown format:

    def my_action
      respond_to do |format|
        format.json { head :ok }
        format.any { render text: 'Default response' }
      end
    end

we should render the default response instead of raising ActionController::UnknownFormat

Fixes #14462

Conflicts:
	actionpack/CHANGELOG.md
	actionpack/test/controller/mime/respond_with_test.rb

Conflicts:
	actionpack/CHANGELOG.md

No variant should also be picked up by variant.any if variant.none is not defined (just like any other variant)

Allow setting `request.variant` as an array - an order in which they will be
rendered.

For example:

  request.variant = [:tablet, :phone]

  respond_to do |format|
    format.html.none
    format.html.phone # this gets rendered
  end

Like `format.any`, you can do the same with variants.

It works for both inline:

    respond_to do |format|
      format.html.any   { render text: "any"   }
      format.html.phone { render text: "phone" }
    end

and block syntax:

    respond_to do |format|
      format.html do |variant|
        variant.any(:tablet, :phablet){ render text: "any" }
        variant.phone { render text: "phone" }
      end
    end

In most cases, when setting variant specific code, you're not sharing any code
within format.

Inline syntax can vastly simplify defining variants in those situations:

  respond_to do |format|
    format.js { render "trash" }
    format.html do |variant|
      variant.phone { redirect_to progress_path }
      variant.none  { render "trash" }
    end
  end

Becomes:

  respond_to do |format|
    format.js         { render "trash" }
    format.html.phone { redirect_to progress_path }
    format.html.none  { render "trash" }
  end

This reverts commit 18616114, reversing
changes made to cad9eb17.

In most cases, when setting variant specific code, you're not sharing any code
within format.

Inline syntax can vastly simplify defining variants in those sitiations:

  respond_to do |format|
    format.js { render "trash" }
    format.html do |variant|
      variant.phone { redirect_to progress_path }
      variant.none  { render "trash" }
    end
  end
`
Becomes:

  respond_to do |format|
    format.js         { render "trash" }
    format.html.phone { redirect_to progress_path }
    format.html.none  { render "trash" }
  end