Statement caches are used as a concurrent map. It will more clarify to
using `Concurrent::Map`.

Actually `StatementCache#execute` is always passed the same klass that
the owner klass of the connection when the statement cache is created.
So passing `klass` to `StatementCache.new` will make more DRY.

Making sure the table name is parsed correctly when an add/remove column migration have 'from'/'to' in the table name.

And make reference to `Relation`.

It seems that it accepts only HTTPS connections.
Ref: https://github.com/postgres/postgres/commit/7f77cbd996855a06fb742ea11adbe55c42b48fe2

For less duplicated code.

We were expecting those classes to be loaded when an association is
defined but they are not.

If you add a debugger on the first line of any of those classes and try
to define the corresponding association you will see that the classes
are not loaded.

Fixes #26273

Anywhere that we're doing `self.class.unscoped.where(primary_key => id)`
is somewhere that someone may want to extend. Even if this method isn't
public API yet, this will make it easier for us to eventually expose an
API around this. Plus, duplicated code makes me sad.

Condenses the clauses that are common to both sides of the OR and put them outside, before the OR
This fix the current behavior where the number of conditions is exponential based on the number of times #or is used.

Building `where_clause` manually was introduced at #26073 to include
both `comparison` and `binds` in `where_clause`. Since 213796fb,
`comparison` includes `binds`, so it is enough to use `where` simply.

The limit option is ignored by PostgreSQL and may be ignored by 3rd
party backends.  Make this clear in the docs.  Fixes #29922.

Note that the two relations must still have the same `includes` values
(which is the only time `references` actually does anything). It makes
sense for us to allow this, as `references` is called implicitly when
passing a hash to `where`.

Fixes #29411

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

Without this change, bundler will resolve a gemfile which is pointing at
Rails master and not arel master. The error message that someone will
get from doing this will be incredibly unhelpful, as it'll be the result
of ActiveRecord being in a half-loaded that halted at `require
"arel/collectors/composite"`, which was subsequently rescued in
`"rails/all"`

`bind_values` was removed from Arel

Since 213796fb, `queries_predicates` is no longer used.

Since 213796fb removed `binds`, `JoinInformation` only contain `joins`.
So it is enough to return `joins` simply.

When generating models, we created ApplicationRecord in the default
location if no file existed there.  That was annoying for people who
moved it to somewhere else in the autoload path.  At this point, the
vast majority of apps should have either run the upgrade script or
generated a model since upgrading.  For those that haven't the error
message after generating a new model should be helpful:

   NameError: uninitialized constant ApplicationRecord

To ease friction in that case, this also adds a generator for
ApplicationRecord.

```
% ARCONN=sqlite3 be ruby -w -Itest test/cases/associations/belongs_to_associations_test.rb -n test_multiple_counter_cache_with_after_create_update
test/cases/associations/belongs_to_associations_test.rb:1181: warning: assigned but unused variable - comment
Using sqlite3
Run options: -n test_multiple_counter_cache_with_after_create_update --seed 49644

.

Finished in 0.114266s, 8.7515 runs/s, 17.5030 assertions/s.

1 runs, 2 assertions, 0 failures, 0 errors, 0 skips
```

Currently `Relation#merge` will almost fill `values` with empty values
(e.g. `other.order_values` is always true, it should be
`other.order_values.any?`). This means that `Relation#merge` always
changes `values` even if actually `values` is nothing changed. This
behavior will makes `Relation#empty_scope?` fragile. So `Relation#merge`
should avoid unnecessary changes.

This also reverts the change to enable prepared statements by default on
MySQL (though I suspect we could enable them and it'd be great). This
change brings back a collector closer to the old `Bind` collector in
Arel. However, this one lives in AR, since this is an AR specific need.
Additionally, we only use it for statement caching, since the new
substitute collector in Arel is higher performance for most cases.

Honestly I don't think the tests that are fixed by this change should
have been merged. Passing a range or an array to `where` has a special
meaning. We need to solve the problem more concretely without overriding
the behavior that is present for *every* other type.

However, the damage has been done. These changes were in 5.1, so we need
a deprecation cycle to remove it.

There's an actual bug in 213796fb around
prepared statements being disabled. I'm looking into it, but in the mean
time this gets the build green so it doesn't block other PRs

A common source of bugs and code bloat within Active Record has been the
need for us to maintain the list of bind values separately from the AST
they're associated with. This makes any sort of AST manipulation
incredibly difficult, as any time we want to potentially insert or
remove an AST node, we need to traverse the entire tree to find where
the associated bind parameters are.

With this change, the bind parameters now live on the AST directly.
Active Record does not need to know or care about them until the final
AST traversal for SQL construction. Rather than returning just the SQL,
the Arel collector will now return both the SQL and the bind parameters.
At this point the connection adapter will have all the values that it
had before.

A bit of this code is janky and something I'd like to refactor later. In
particular, I don't like how we're handling associations in the
predicate builder, the special casing of `StatementCache::Substitute` in
`QueryAttribute`, or generally how we're handling bind value replacement
in the statement cache when prepared statements are disabled.

This also mostly reverts #26378, as it moved all the code into a
location that I wanted to delete.

/cc @metaskills @yahonda, this change will affect the adapters

Fixes #29766.
Fixes #29804.
Fixes #26541.
Close #28539.
Close #24769.
Close #26468.
Close #26202.

There are probably other issues/PRs that can be closed because of this
commit, but that's all I could find on the first few pages.

The queries both `res2` and `res3` are completely the same.
And also, `assert_nothing_raised` is covered by following assertion.

This was missed when the frozen string literal pragma was added to this
file because the string is only modified when running in the context of
a full Rails app, which wasn't covered by the test suite.

Reverts 7abb6e00.

Since #26972, `ORDER BY` is kept if `LIMIT` is presented for
performance. But in most SQL servers (e.g. PostgreSQL, SQL Server, etc),
`ORDER BY` expressions must appear in select list for `SELECT DISTINCT`.
We should not replace existing select list in that case.

This reverts commit b6ad4052.

This is not something that the majority of Active Record should be
testing or care about. We should look at having fewer places rely on
these details, not make it easier to rely on them.

When a has_many association is destroyed by `dependent: destroy`,
destroyed_by_association is set to the reflection, and this can be
checked in callbacks.  This matches that behaviour for has_one
associations.

This fixes the following failures.
https://travis-ci.org/rails/rails/jobs/253990014

`type_map` is an internal API and it is only used in the connection
adapter. And also, some type map initializer methods requires passed
`type_map`, but those instances already has `type_map` in itself.
So we don't need explicit passing `type_map` to the initializers.