This is a private place to put those AS features that are used
by every component. Nowadays we cherry-pick individual files
wherever they are used, but that it is not worth the effort
for stuff that is going to be loaded for sure sooner or later,
like blank?, autoload, concern, etc.

set AD::IntegrationTest.app in railtie initializer

Signed-off-by: NSantiago Pastorino <santiago@wyeworks.com>

Based on the implementation on the 2-3-stable branch, patches by Hongli
Lai <hongli@phusion.nl>, and helpful suggestions from José Valim.

Hongli Lai's patches included locking around the request cycle; this is
now handled by Rack::Lock (https://github.com/rack/rack/issues/issue/87/).

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

This removes all deprecated classes in ActionController related to
Routing, Abstract Request/Response and Integration/IntegrationTest.
All tests and docs were changed to ActionDispatch instead of ActionController.

Add a header that tells Internet Explorer (all versions) to use the best available standards support. This ensures that IE doesn't go into quirks mode because it has been blacklisted by too many users pressing the incompatible button. It also tells IE to use the ChromeFrame renderer, if the user has installed the plugin.

This guarantees that the best available standards support will be used on the client.

Signed-off-by: Nwycats <wycats@gmail.com>

If you have existing Metals, you have a few options:
* if your metal behaves like a middleware, add it to the
  middleware stack via config.middleware.use. You can use
  methods on the middleware stack to control exactly where
  it should go
* if it behaves like a Rack endpoint, you can link to it
  in the router. This will result in more optimal routing
  time, and allows you to remove code in your endpoint
  that matches specific URLs in favor of the more powerful
  handling in the router itself.

For the future, you can use ActionController::Metal to get
a very fast controller with the ability to opt-in to specific
controller features without paying the penalty of the full
controller stack.

Since Rails 3 is closer to Rack, the Metal abstraction is
no longer needed.

If you have existing Metals, you have a few options:
* if your metal behaves like a middleware, add it to the
  middleware stack via config.middleware.use. You can use
  methods on the middleware stack to control exactly where
  it should go
* if it behaves like a Rack endpoint, you can link to it
  in the router. This will result in more optimal routing
  time, and allows you to remove code in your endpoint
  that matches specific URLs in favor of the more powerful
  handling in the router itself.

For the future, you can use ActionController::Metal to get
a very fast controller with the ability to opt-in to specific
controller features without paying the penalty of the full
controller stack.

Since Rails 3 is closer to Rack, the Metal abstraction is
no longer needed.

  * ActionController::Base.ip_spoofing_check deprecated => config.action_dispatch.ip_spoofing_check
  * ActionController::Base.trusted_proxies deprecated => config.action_dispatch.trusted_proxies

Move filter_parameter_logging logic out of the controller and create ActionDispatch::ParametersFilter to handle parameter filteration instead. This will make filteration not depending on controller anymore.
Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Removes load path change from commit bb153f42.