Deprecate leaking scope in callback block for association relation

Fix preloading on AR::Relation where records are duplicated by a join

This reverts commit a1ee4a9f.

Even if a1ee4a9f is applied, CI is still flakiness.

https://buildkite.com/rails/rails/builds/61252#2c090afa-aa84-4a2b-8b81-9f09219222c6/994-1005
https://buildkite.com/rails/rails/builds/61252#2e55bf83-1bde-44a2-a4f1-b5c3f6820fb4/929-938

Failing tests by whether schema cache is filled or not, it actually
means that whether SCHEMA SQLs are executed or not is not target for the
tests.

So I've reverted commit a1ee4a9f which filling schema cache before
`assert_no_queries`, and replace `assert_no_queries` to
`assert_queries(0)`.

Don't track implicit `touch` mutation

If an association has a scope, `automatic_inverse_of` is to be disabled.
But extension block is obviously not a scope. It should not be regarded
as a scope.

Fixes #28806.

The special case happens when through association has a custom scope
that is applied to the source association when loading.
In this case, the soucre association would need to be reset after
main association is loaded. See tests.

The special case exists when a through association has

This reverts commit eec3e28a, reversing
changes made to 5588fb48.

Reason: Marking as loaded without actual loading is too greedy optimization.

See more context #35239.

Closes #35239.

[Edouard CHIN & Ryuta Kamizono]

Formerly it was returning arguments (`records` array).

Since 31ffbf8d, finder methods no longer raise `RangeError`. So
`StatementCache#execute` is the only place to raise the exception for
finder queries.

`StatementCache` is used for simple equality queries in the codebase.
This means that if `StatementCache#execute` raises `RangeError`, the
result could always be regarded as empty.
So `StatementCache#execute` just return nil in that range error case,
and treat that as empty in the caller side, then we can avoid catching
the exception in much places.

This PR addresses the issue described in #28025. On `dependent: :nullify` strategy only the foreign key of the relation is nullified. However on polymorphic associations the  `*_type` column is not nullified leaving the record with a NULL `*_id` but the `*_type` column is present.

Unlike the `Relation#delete_all`, `delete_all` on collection proxy
doesn't return affected count. Since the `CollectionProxy` is a subclass
of the `Relation`, this inconsistency is probably not intended, so it
should return the count consistently.

Reset scope after delete on collection association to clear stale
offsets of removed records.

https://travis-ci.org/rails/rails/jobs/459534536#L1280

The delegation methods to named scope are defined when `method_missing`
is invoked on the relation.

Since #29301, the receiver in the named scope is changed to the relation
like others (e.g. `default_scope`, etc) for consistency.

Most named scopes would be delegated from relation by `method_missing`,
since we don't allow scopes to be defined which conflict with instance
methods on `Relation` (#31179). But if a named scope is defined with the
same name as any method on the `superclass` (e.g. `Kernel.open`), the
`method_missing` on the relation is not invoked.

To address the issue, make the delegation methods to named scope is
generated in the definition time.

Fixes #34098.

Follow up 45be690f.

Somehow calling `define_attribute_methods` in `build`/`new` sometimes
causes the `table_exists?` query.

To address CI flakiness due to `assert_no_queries` failure, ensure
`define_attribute_methods` before `assert_no_queries`.

Since #31575, `set_inverse_instance` replaces the foreign key by the
current owner immediately to make it happen when a record is added to
collection association.

But `set_inverse_instance` is not only called when a record is added,
but also when a record is loaded from queries. And also, that loaded
records are not always associated records for some reason (using `or`,
`unscope`, `rewhere`, etc).

It is hard to distinguish whether or not we should invoke
`set_inverse_instance`, but at least we should avoid the undesired
side-effect which was brought from #31575.

Fixes #34108.

Follow up 811be477.

`test_update_does_not_run_sql_if_record_has_not_changed` would pass
without #18501 since `assert_queries` ignores BEGIN/COMMIT unless
`ignore_none: true` is given.

Since #32647, empty BEGIN/COMMIT is ommited. So we no longer need to use
`assert_queries(0)` to ignore BEGIN/COMMIT in the queries.

This reverts commit 376ffe0e.

Since 38fae1f2, `association.increment_counters` is called without
inflated parent target if inverse_of is disabled.
In that case, that commit would cause extra queries to inflate parent.

Fixes #19550.

There is test in has_one to test enum, but there is no for has_many.

[Rich Chen]

Six Mocha calls prove quite resistant to Minitestification. For example,
if we replace

```
  ActiveRecord::Associations::HasManyAssociation
    .any_instance
    .expects(:reader)
    .never
```

with `assert_not_called`, Minitest wisely raises

```
NameError: undefined method `reader' for class `ActiveRecord::Associations::HasManyAssociation'
```

as `:reader` comes from a deeply embedded abstract class,
`ActiveRecord::Associations::CollectionAssociation`.

This patch tackles this difficulty by adding
`ActiveSupport::Testing::MethodCallAsserts#assert_called_on_instance_of`
which injects a stubbed method into `klass`, and verifies the number of
times it is called, similar to `assert_called`. It also adds  a convenience
method, `assert_not_called_on_instance_of`, mirroring
`assert_not_called`.

It uses the new method_call_assertions to replace the remaining Mocha
calls in `ActiveRecord` tests.

[utilum + bogdanvlviv + kspath]

In `_create_record`, explicit `transaction` block requires rollback
handling manually when `insert_record` is failed.

We need to handle it in `_create_record`, not in `insert_record`, since
our test cases expect a record added to target and returned even if
`insert_record` is failed,

Closes #31488.

Follow up of #32605.

Currently `ids_reader` doesn't respect dirty target when the target is
not loaded yet unlike `collection.size`. I believe the inconsistency is
a bug, fixes the `ids_reader` to behave consistently regardless of
whether target is loaded or not.

Already loaded associations were running an extra query when `size` was called on the association.
This fix ensures that an extra query is no longer run.

Update tests to use proper methods

This autocorrects the violations after adding a custom cop in
3305c78dcd.

https://travis-ci.org/rails/rails/jobs/360109429

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