This reverts commit 4147ab73.

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

we want to go through methods to access `env` because in the future that
ivar may not be available, or may be calculated lazily

Wrapping an array in an `ArrayInquirer` gives a friendlier way to check its
string-like contents. For example, `request.variant` returns an `ArrayInquirer`
object. To check a request's variants, you can call:

    request.variant.phone?
    request.variant.any?(:phone, :tablet)

...instead of:

    request.variant.include?(:phone)
    request.variant.any? { |v| v.in?([:phone, :tablet]) }

`Array#inquiry` is a shortcut for wrapping the receiving array in an
`ArrayInquirer`:

    pets = [:cat, :dog]
    pets.cat?    # => true
    pets.ferret? # => false
    pets.any?(:cat, :ferret} # => true

Closes #18933.

The current implementation of `variants=` don't allow a resetting to nil, wich is the default value.

This results in the following code smell:
```ruby
case request.user_agent
when /iPhone/
  request.variants = :phone
when /iPad/
  request.variants = :ipad
end
```

With the ability to reset variants to nil, it could be:
```ruby
request.variants = case request.user_agent
when /iPhone/
  :phone
when /iPad/
  :ipad
end
```

As Rack has some non backwards compatible changes added required
modifications to keep behaviour in rails close to same as before.

Also modified generators to include rack/rack for not yet released
version of rack

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

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

TLDR: always return an object that responds to the query methods from
request.format, and do not touch Mime::Type[] lookup to avoid bugs.

---

Long version:

The initial issue was about being able to do checks like
request.format.html? for request with an unknown format, where
request.format would be nil.

This is where the issue came from at first in #7837 and #8085
(merged in cba05887), but the
implementation went down the path of adding this to the mime type
lookup logic.

This unfortunately introduced subtle bugs, for instance in the merged
commit a test related to send_file had to be changed to accomodate the
introduction of the NullType.

Later another bug was found in #13064, related to the content-type being
shown as #<Mime::NullType:...> for templates with localized extensions
but no format included. This one was fixed in #13133, merged in
43962d6e.

Besides that, custom handlers were not receiving the proper template
formats anymore when passing through the rendering process, because of
the NullType addition. That was found while migrating an application
from 3.2 to 4.0 that uses the Markerb gem (a custom handler that
generates both text and html emails from a markdown template).

---

This changes the implementation moving away from returning this null
object from the mime lookup, and still fixes the initial issue where
request.format.zomg? would raise an exception for unknown formats due to
request.format being nil.

Avoid one-liner conditionals when they are too big. Avoid concatenating
strings to build error messages. Improve messages a bit.

By default, variants in the templates will be picked up if a variant is set
and there's a match. The format will be:

  app/views/projects/show.html.erb
  app/views/projects/show.html+tablet.erb
  app/views/projects/show.html+phone.erb

If request.variant = :tablet is set, we'll automatically be rendering the
html+tablet template.

In the controller, we can also tailer to the variants with this syntax:

  class ProjectsController < ActionController::Base
    def show
      respond_to do |format|
        format.html do |html|
          @stars = @project.stars

          html.tablet { @notifications = @project.notifications }
          html.phone  { @chat_heads    = @project.chat_heads }
        end

        format.js
        format.atom
      end
    end
  end

The variant itself is nil by default, but can be set in before filters, like
so:

  class ApplicationController < ActionController::Base
    before_action do
      if request.user_agent =~ /iPad/
        request.variant = :tablet
      end
    end
  end

This is modeled loosely on custom mime types, but it's specifically not
intended to be used together. If you're going to make a custom mime type,
you don't need a variant. Variants are for variations on a single mime
types.

Fix ActionDispatch::Request#formats on xhr requests when HTTP_ACCEPT
header is empty string. About issue #7774, same fix as in commit bebb02fd
but for xhr requests.

This reverts commit fa6d921e.

Reason: Not a fan of such massive changes. We usually close such changes
if made to Rails master as a pull request. Following the same principle
here and reverting.

[ci skip]

For future reference, this is the regex I used: ^\s*#\s*\n(?!\s*#). Replace
with the first match, and voilà! Note that the regex matches a little bit too
much, so you probably want to `git add -i .` and go through every single diff
to check if it actually should be changed.

An xhr request must have an "Accept" or "Content-type" header in order to be considered a request with valid_accept_header.

Signed-off-by: NJosé Valim <jose.valim@gmail.com>

leading */* and comma
Signed-off-by: NJosé Valim <jose.valim@gmail.com>

has ....,*/* .

It is possible to a device to send
request such that */* appear at the beginning of the
"Accept" header. This patch ensures that "Accept" header
is ignored for such cases too.
Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Slightly less annoying check for acceptable mime_types. This allows Accept: application/json, application/jsonp (and the like), but still blacklists browsers. Essentially, we use normal content negotiation unless you include */* in your list, in which case we assume you're a browser and send HTML [#3541 state:resolved]

it to return a String. Split the Rails API so that Request#content_type returns
a String, and Request#content_mime_type returns a Mime::Type object.