[fixes #18606]

Make belongs_to use touch over touch_later when running the callbacks.

Add more tests and small method rename

Thanks Jeremy for the feedback.

Deprecate `required` option in favor of `optional` for belongs_to.

`Computer` class needs to be require

See #17217 for more details

fixes #17495

Isolate access to @associations_cache and @aggregations cache to the Associations and Aggregations modules, respectively.

This includes replacing the `association_cache` accessor with a more
limited `association_cached?` accessor and making `clear_association_cache`
and `clear_aggregation_cache` private.

This reverts commit e84799d9, e31104c1 and e6ca8e2c

Reliant on https://github.com/rails/rails/pull/15747 but pulled to a
separate PR to reduce noise. `has_many :through` associations have the
undocumented behavior of automatically detecting counter caches.
However, the way in which it does so is inconsistent with counter caches
everywhere else, and doesn't actually work consistently.

As with normal `has_many` associations, the user should specify the
counter cache on the `belongs_to`, if they'd like it updated.

The foreign_key could be `String` and just doing `owners_map[owner_key]`
could return `nil`.
To prevent this bug, we should `to_s` both keys if their types are
different.

Fixes #14734.

Follow up to af549a1a

Backport test from #14410

Prior to Rails 4.0.4 when touching a object which doesn't have timestamp
attributes (updated_at / updated_on) rails would still touch all
associations. After 73ba2c14 it updates
associations but rollsback because `touch` would return nil since
there's no timestamp attribute

 This is to ensure that they are not accidentally called by the app code.
 They are renamed to _create_record and _update_record respectively.
 Closes #11645

Dangerous association names conflicts include instance or class
methods already defined by `ActiveRecord::Base`.

Since Rails 4.0, we add an ORDER BY in the `first` method to ensure consistent
results among different database engines. But for singular associations this
behavior is not needed since we will have one record to return. As this
ORDER BY option can lead some performance issues we are removing it for singular
associations accessors.

Fixes #12623.

Fixes: #13445

removed unnecessary test case and improved test case for belongs_to having invalid  options

if belongs to model with touch option on touch

Closes #11288

simplified logic to calculate number of queries by using assert_queries

counter cache

At present, calling destroy multiple times on the same record results
in the belongs_to counter cache being decremented multiple times. With
this change the record is checked for whether it is already destroyed
prior to decrementing the counter cache.

This commit fixes a bug introduced in 96a13fc7 which breaks behaviour of
integer fields.

In 3.2.8, setting the value of an integer field to a non-integer (eg.
Array, Hash, etc.) would default to 1 (true) :

    # 3.2.8
    p = Post.new
    p.category_id = [ 1, 2 ]
    p.category_id # => 1
    p.category_id = { 3 => 4 }
    p.category_id # => 1

In 3.2.9 and above, this will raise a NoMethodError :

    # 3.2.9
    p = Post.new
    p.category_id = [ 1, 2 ]

    NoMethodError: undefined method `to_i' for [1, 2]:Array

Whilst at first blush this appear to be sensible, it combines in bad
ways with scoping.

For example, it is common to use scopes to control access to data :

    @collection = Posts.where(:category_id => [ 1, 2 ])
    @new_post = @collection.new

In 3.2.8, this would work as expected, creating a new Post object
(albeit with @new_post.category_id = 1). However, in 3.2.9 this will
cause the NoMethodError to be raised as above.

It is difficult to avoid triggering this error without descoping before
calling .new, breaking any apps running on 3.2.8 that rely on this
behaviour.

This patch deviates from 3.2.8 in that it does not retain the somewhat
spurious behaviour of setting the attribute to 1. Instead, it explicitly
sets these invalid values to nil :

    p = Post.new
    p.category_id = [ 1, 2 ]
    p.category_id # => nil

This also fixes the situation where a scope using an array will
"pollute" any newly instantiated records.

    @new_post = @collection.new
    @new_post.category_id # => nil

Finally, 3.2.8 exhibited a behaviour where setting an object to an
integer field caused it to be coerced to "1". This has not been
retained, as it is spurious and surprising in the same way that setting
Arrays and Heshes was :

    c = Category.find(6)
    p = Post.new

    # 3.2.8
    p.category_id = c
    p.category_id # => 1

    # This patch
    p.category_id = c
    p.category_id # => nil

This commit includes explicit test cases that expose the original issue
with calling new on a scope that uses an Array. As this is a common
situation, an explicit test case is the best way to prevent regressions
in the future.

It also updates and separates existing tests to be explicit about the
situation that is being tested (eg. AR objects vs. other objects vs.
non-integers)

Allows you to do BaseClass.new(:type => "SubClass") as well as
parent.children.build(:type => "SubClass") or parent.build_child
to initialize an STI subclass. Ensures that the class name is a
valid class and that it is in the ancestors of the super class
that the association is expecting.

Method compilation provides better performance and I think the code
comes out cleaner as well.

A knock on effect is that methods that get redefined produce warnings. I
think this is a good thing. I had to deal with a bunch of warnings
coming from our tests, though.