The problem was that when saving an object, we would
call touch_later on the parent which wont be saved immediteally, and
it wont call any callbacks. That was working one level up because
we were calling touch, during the touch_later commit phase. However that still
didnt solve the problem when you have a 3+ levels of parents to be touched,
as calling touch would affect the parent, but it would be too late to run callbacks
on its grand-parent.

The solution for this, is instead, call touch_later upwards when the first
touch_later is called. So we make sure all the timestamps are updated without relying
on callbacks.

This also removed the hard dependency BelongsTo builder had with the TouchLater module.
So we can still have the old behaviour if TouchLater module is not included.

[fixes 5f5e6d92]
[related #19324]

We don't want to commit the cookie jar more than once because then we
will be attempting to modify a frozen hash.

Fixes Railties test failure caused by 492b1344.

This adds a new method to request and response so we don't need to
violate the law of demeter.

We are changing `Request` and `Response` so that they always have a
`cookie_jar`

This is a continuation on work to combine integration and controller
test code bases in Rails.

We want to get rid of the `Live::Response` so we are consolidating methods
from `Live::Response` and `Response` by merging them together.

This adds an `#empty` method to the request so we don't need to
hard-code the empty array each time we call an empty
`ActionDispatch::Request`.

The work here is a continuation on combining controller and integration
test code bases into one.

Introduce after_{create,update,delete}_commit callbacks

Those are actually shortcuts for `after_commit`.

Before:

    after_commit :add_to_index_later, on: :create
    after_commit :update_in_index_later, on: :update
    after_commit :remove_from_index_later, on: :destroy

After:

    after_create_commit  :add_to_index_later
    after_update_commit  :update_in_index_later
    after_destroy_commit :remove_from_index_later

Subscribing to notifications while inside the said instrumented section

Test against the real value of tld_length unless explicitly set

add test for namespaced model name translation

Reading `Rails::Commands::Command` feels excessive. Especially if users can subclass command
to write their own commands — which I'd like to aim for.

Switch to `Rails::Command` before we get too far into things.

We should first attempt to run commands through Rails command, and then
fall back to trying the commands tasks.

Because eventually the commands tasks should be their own commands.

When attempting to run a `rake` task with `bin/rails`, Rails would see
check that a Rake task existed and ask users if they meant to run it with
rake.

We don't need that anymore, as the goal is to have `rails` be a valid way
to run rake tasks.

The class level version is responsible for changing a task name to
command name, then finding a command and run it if there is one.

The instance level `run` then makes sure arguments have been parsed
into `@options` and runs the command by sending it.

`Rails::Commands::Command.run` returns true to make it work within
`Rails::CommandsTask`, but won't in the future when it handles
all option parsing.

 Add redirection path in the error message of assert_response if response is :redirect

When `parse_options_for` was called for a command that
hadn't set up any option parsing with `options_for`, the `call` method
would be sent to `-> {}`, which didn't like to be passed two arguments.

Switch to `proc {}` which can accept several arguments.

even if a write fails, store the raw value

I want to streamline the wording around `command`, and not
start pondering about instances.

The `ARGV` constant in Ruby is not a string, it's an array as demonstrated
by running:

```
$ ruby -e "p ARGV"
=> []
$
$ ruby -e "p ARGV" test/file.rb --version=2
=> ["test/file.rb", "--version=2"]
```

  * Ditch the instance methods local variable.

  * Prefer Ruby's default nil return, and remove else branch.

Checking that a command exists before running it is an implementation detail
of the Rails command and Rake task world right now.

Eventually I'd like to get rid of `exists?`, when I've worked out another way
to fall back to run the old tasks.

Users shouldn't have to lookup the command name for a task. Put it in
the private section, so it doesn't show up in any generated documentation.

The previous spelling seemed a bit too generous with the whitespace, and
looked out of place when amongst others.

Add note about serialization to update_columns documentation [ci skip]

remove warning from postgresql geometric test

This removes the following warning which has been out in the case of a PostgreSQL 9.3 below.

```
activerecord/test/cases/adapters/postgresql/geometric_test.rb:265: warning: instance variable @connection not initialized
```

Add Rails command infrastructure

There were two places where the tld_length default
was hard-coded to 1, both overriding the real default
value of ActionDispatch::Http::URL.tld_length in this
set of tests.

This commit removes both of those, relying on the
actual value of ActionDispatch::Http::URL.tld_length,
unless it's specifically overridden.

- If the assert_response is checking for any non-redirect response like
  :success and actual response is :redirect then, the error message displayed
  was -

     Expected response to be a <success>, but was <302>

- This commit adds the redirect path to the error message of
  assert_response if the response is :redirect.
  So above message is changed to -

     Expected response to be a <success>, but was a redirect to <http://test.host/posts/lol>

Replace ActionMailer::Base.respond_to? with respond_to_missing?

Fix the Railties tests

Railsties tests are broken with this new update checker so we will use
the old one until we have the tests fixed.

Related with e62ddac0

Related with 668c006c.

Remove old comment about AC::Parameters>subclasses