When a belongs to association's target is set, its foreign key is now
updated to match the new target. This is the correct behaviour when a
new record is assigned, but not when the existing record is preloaded.

As long as we mark the association as loaded, we can skip setting the
target when the record is missing and avoid clobbering the foreign key.

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.

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.

Since #32028, Rails 6 requires Ruby 2.3+.
No longer needed workaround for Ruby 2.2 "private attribute?" warning.

With #31615 `type_for_attribute` accepts either
a symbol as well as a string. `has_attribute?` and `attribute_alias`
also accept either. Since these methods call `to_s` on the argument,
we no longer need to do that at the call site.

They are only different by one line of code which doesn't deserve a
hierarchy of 7 classes.

Closes #31079.

[Ryuta Kamizono & Bogdan Gusiev]

`associated_records_by_owner` had returned customizing result before
calling `associate_records_to_owner` for through association subclasses.
Since #22115, `associate_records_to_owner` is called in the method and
not returned owner and result pairs. Removing the method will reduce
method call and block call nesting.

Benchmark Script:
```
require 'active_record'
require 'benchmark/ips'

ActiveRecord::Base.establish_connection(ENV.fetch('DATABASE_URL'))
ActiveRecord::Migration.verbose = false

ActiveRecord::Schema.define do
  create_table :users, force: true do |t|
    t.string :name, :email
    t.integer :topic_id
    t.timestamps null: false
  end

  create_table :topics, force: true do |t|
    t.string :title
    t.timestamps null: false
  end
end

attributes = {
  name: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit.',
  email: 'foobar@email.com'
}

class Topic < ActiveRecord::Base
  has_many :users
end

class User < ActiveRecord::Base
  belongs_to :topic
end

100.times do
  User.create!(attributes)
end

users = User.first(50)

Topic.create!(title: 'This is a topic', users: users)

Benchmark.ips do |x|
  x.config(time: 10, warmup: 5)

  x.report("preload") do
    User.includes(:topic).all.to_a
  end
end
```

Before:
```
Calculating -------------------------------------
             preload    40.000  i/100ms
-------------------------------------------------
             preload    407.962  (± 1.5%) i/s -      4.080k
```

After:
```
alculating -------------------------------------
             preload    43.000  i/100ms
-------------------------------------------------
             preload    427.567  (± 1.6%) i/s -      4.300k
```

Since we have `Preloader#preload`, `Preloader::Association#preload` is a
little confusing. And also, since the `preload` method is an abstract
method, it is hard to read where `associated_records_by_owner` is
called. This refactors `Preloader::Association` to ease to read where
`associated_records_by_owner` is called.

```
require 'active_record'
require 'benchmark/ips'

ActiveRecord::Base.establish_connection(ENV.fetch('DATABASE_URL'))
ActiveRecord::Migration.verbose = false

ActiveRecord::Schema.define do
  create_table :users, force: true do |t|
    t.string :name, :email
    t.integer :topic_id
    t.timestamps null: false
  end

  create_table :topics, force: true do |t|
    t.string :title
    t.timestamps null: false
  end
end

attributes = {
  name: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit.',
  email: 'foobar@email.com'
}

class Topic < ActiveRecord::Base
  has_many :users
end

class User < ActiveRecord::Base
  belongs_to :topic
end

100.times do
  User.create!(attributes)
end

users = User.first(50)

100.times do
  Topic.create!(title: 'This is a topic', users: users)
end

Benchmark.ips do |x|
  x.config(time: 10, warmup: 5)

  x.report("preload") do
    User.includes(:topic).all.to_a
  end
end
```

```
Calculating -------------------------------------
             preload    25.000  i/100ms
-------------------------------------------------
             preload    251.772  (± 1.2%) i/s -      2.525k
```

```
Calculating -------------------------------------
             preload    26.000  i/100ms
-------------------------------------------------
             preload    270.392  (± 1.1%) i/s -      2.704k
```

If `reflection.scope` isn't given, `reflection_scope` is always
`klass.unscoped`. it is unnecessary to merge it.

Defined scope treats nil as `all`, but scope in associations isn't so.
If the result of the scope is nil, most features on associations will be
broken. It should treat nil as `all` like defined scope.

Fixes #20823.

Follow up of #29834.

Fixes #30266.

Since 213796fb, array predicate handler supports making binds, so the
preprocess is no longer needed.

Currently preload query cannot be prepared statements even if
`prepared_statements: true` due to array handler in predicate builder
doesn't support making bind params. This makes preload query to
preparable by don't passing array value if possible.

These are no longer used since b98668de.

This reverts commit 3420a145, reversing
changes made to afb66a5a.

If a parent association was accessed in an `after_find` or
`after_initialize` callback, it would always end up loading the
association, and then immediately overwriting the association we just
loaded. If this occurred in a way that the parent's `current_scope` was
set to eager load the child, this would result in an infinite loop and
eventually overflow the stack.

For records that are created with `.new`, we have a mechanism to
perform an action before the callbacks are run. I've introduced the same
code path for records created with `instantiate`, and updated all code
which sets inverse instances on newly loaded associations to use this
block instead.

Fixes #26320.

Fixes #24093

This still isn't as separated as I'd like, but it at least moves most of
the burden of alias mapping in one place.

This reverts commit 537ac7d6, reversing
changes made to 9c9c54ab.

Reason:
The way we preload associations will change the meaning of GROUP BY
operations. This is illustrated in the SQL generated by the added
test (failing on PG):

Association Load:
D, [2015-12-21T12:26:07.169920 #26969] DEBUG -- :   Post Load (0.7ms)  SELECT "posts".* FROM "posts" LEFT JOIN comments ON comments.post_id = posts.id WHERE "posts"."author_id" = $1 GROUP BY posts.id ORDER BY SUM(comments.tags_count)  [["author_id", 1]]

Preload:
D, [2015-12-21T12:26:07.128305 #26969] DEBUG -- :   Post Load (1.3ms)  SELECT "posts".* FROM "posts" LEFT JOIN comments ON comments.post_id = posts.id WHERE "posts"."author_id" IN (1, 2, 3) GROUP BY posts.id ORDER BY SUM(comments.tags_count)

Fixes problem when added `group()` in association scope was lost
in eager loaded association.

This is part of a refactoring to make it easier to allow `order` to use
sanitize like just about everything else on relation. The deleted test
doesn't give any reasoning as to why passing `nil` to `order` needs to
be supported, and it's rather nonsensical. I can almost see allowing an
empty string being passed (though I'm tempted to just disallow it...)

This reverts commit 52439460.

This fixes an issue with the build where tests would fail on mysql and
postgresql due to different ordering.

This reverts commit 6dc6a0b1, reversing
changes made to ec94f00b.

This pull request broke the build.

We should call `scope.order!` and set `scope.reordering_value` to `true` if :reordering values are specified

Fixes #21886

* less arrays created
* less complexity with only one level of nesting in loop