When a class has a belongs_to or has_one relationship with dependent: :destroy
option enabled, objects of this class should not be deleted if it's dependents
cannot be deleted.

Example:

    class Parent
      has_one :child, dependent: :destroy
    end

    class Child
      belongs_to :parent, inverse_of: :child
      before_destroy { throw :abort }
    end

    c = Child.create
    p = Parent.create(child: c)

    p.destroy

    p.destroyed? # expected: false; actual: true;

Fixes #32022

This reverts ignoring polymorphic error introduced at 02da8aea.

What the ignoring want to solve was caused by force eager loading
regardless of whether it is necessary, but it has been fixed by #29043.

The ignoring is now only causing a mismatch of `exists?` behavior with
`to_a`, `count`, etc. It should behave consistently.

This is an alternative of #29722, and follow up of #32048.

This does not change the current behavior, but makes it easier to modify
all polymorphic names consistently.

Since #31895, build of 2.5 and AR combination failed.
https://travis-ci.org/rails/rails/jobs/346064349#L1638

It seems to be the reason that model is not loading properly, so I added
require. But I'm not sure if this is correct

This is an alternative of #29722, and revert of #29601 and a1fcbd97.

Currently, association creation and normal association finding doesn't
respect `store_full_sti_class`. But eager loading and preloading respect
the setting. This means that if set `store_full_sti_class = false`
(`true` by default), eager loading and preloading can not find
created polymorphic records.

Association creation and finding should work consistently.

This is an alternative of #31877 to fix #31876 caused by #28808.

This issue was caused by a combination of several loose implementation.

* finding automatic inverse association of polymorphic without context (caused by #28808)
* returning `klass` even if `polymorphic?` (exists before #28808)
* loose verification by `valid_inverse_reflection?` (exists before #28808)

This makes `klass` raise if `polymorphic?` not to be misused.
This issue will not happen unless polymorphic `klass` is misused.

Fixes #31876.
Closes #31877.

3acc5d6e was changed the order of scope evaluation from through scope to
the association's own scope to be prioritized over the through scope.
But the sorting order will be prioritized that is evaluated first. It is
unintentional effect, association scope's sorting order should be
prioritized as well.

Fixes #32008.

Closes #31998

Fixes #31762.

When removing a record from a has many through association, the counter
cache was being updated even if the through record halted the callback
chain and prevented itself from being destroyed.

Need reloading when through record has replaced.

Currently reflections keeps the order when first added even if when
redefining association. As a result of the order, redefining through
association which use newly added association will raise
`HasManyThroughOrderError`. We need to redefine reflection order as well
when redefining association.

Fixes #31068.

This is a regression test for #27864.

when model is added to collection association

Follow up of #31432.

Follow up of #31390.

Record saved in save_has_one_association already make call to association.loaded! via record's before_save callback of save_belongs_to_association,
 but this will reload object if accessed in record's validation.

This is partially fixed by e617fb57 when through association has already
loaded. Otherwise, second level through association should respect
`preload_scope`.

Fixes #30242.
Closes #30076.

[Ryuta Kamizono & CicholGricenchos]

If through association has already loaded, `source_type` is ignored to
loaded through records. The loaded records should be filtered by
`source_type` in that case.

Fixes #30904.

`join_scopes` in `PolymorphicReflection` is passed aliased `table`, so
it should be respected for `source_type_scope`.

Closes #13969.
Fixes #13920.
Fixes #15190.

```
% git grep -n trough
activerecord/test/cases/associations/has_many_through_associations_test.rb:1253:  def test_has_many_trough_with_scope_that_has_joined_same_table_with_parent_relation
```

Currently alias tracker only refer a table name, doesn't respect an
alias name. Should use `join.left.name` rather than
`join.left.table_name`.

It should be shared the count of alias tracking in both INNER/LEFT JOINs
to avoid duplicate aliases.

Fixes #30504.
Closes #30410.

Currently we have no test for alias tracking with string joins. I've add
test case for that to catch a future regression.

This test covers the case of 02da8aea.

Previously `exists?` was always eager-loading the includes values. But
now it is eager-loaded only when necessary since 07a611e0.

So the case of the eager-loading had not covered in the test.

For investigating the cause of failure.

https://travis-ci.org/rails/rails/jobs/287474883#L797-L799