When dumping the database schema, Rails will dump foreign key names only
if those names were not generate by Rails. Currently this is determined
by checking if the foreign key name is `fk_rails_` followed by
a 10-character hash.

At [Cookpad](https://github.com/cookpad), we use
[Departure](https://github.com/departurerb/departure) (Percona's
pt-online-schema-change runner for ActiveRecord migrations) to run migrations.
Often, `pt-osc` will make a copy of a table in order to run a long migration
without blocking it. In this copy process, foreign keys are copied too,
but [their name is prefixed with an underscore to prevent name collision
](https://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html#cmdoption-pt-online-schema-change-alter-foreign-keys-method).

In the process described above, we often end up with a development
database that contains foreign keys which name starts with `_fk_rails_`.
That name does not match the ignore pattern, so next time Rails dumps
the database schema (eg. when running `rake db:migrate`), our
`db/schema.rb` file ends up containing those unwanted foreign key names.
This also produces an unwanted git diff that we'd prefer not to commit.

In this PR, I'd like to suggest a way to expose the foreign key name
ignore pattern to the Rails configuration, so that individual projects
can decide on a different pattern of foreign keys that will not get
their names dumped in `schema.rb`.

Most of the time the table and predicate_builder
passed to Relation.new are exactly the
arel_table and predicate builder of the
given klass. This uses klass.arel_table
and klass.predicate_builder as the defaults,
so we don't have to pass them in most cases.

This does change the signaure of both Relation and
AssocationRelation. Are we ok with that?

This new ActiveRecord configuration option allows you to easily
pinpoint what line of application code is triggering SQL queries in the
development log by appending below each SQL statement log the line of
Ruby code that triggered it.

It’s useful with N+1 issues, and to locate stray queries.

By default this new option ignores Rails and Ruby code in order to
surface only callers from your application Ruby code or your gems.

It is enabled on newly generated Rails 5.2 applications and can be
enabled on existing Rails applications:

```ruby
Rails.application.configure do
  # ...
  config.active_record.verbose_query_logs = true
end
```

The `rails app:upgrade` task will also add it to
`config/development.rb`.

This feature purposely avoids coupling with
ActiveSupport::BacktraceCleaner since ActiveRecord can be used without
ActiveRecord. This decision can be reverted in the future to allow more
configurable backtraces (the exclusion of gem callers for example).

These extra `spawn` are called via `klass.all` and `klass.all` is called
everywhere in the internal. Avoiding the extra `spawn` makes` klass.all`
30% faster for STI classes.

https://gist.github.com/kamipo/684d03817a8115848cec8e8b079560b7

```
Warming up --------------------------------------
       fast relation     4.410k i/100ms
       slow relation     3.334k i/100ms
Calculating -------------------------------------
       fast relation     47.373k (± 5.2%) i/s -    238.140k in   5.041836s
       slow relation     35.757k (±15.9%) i/s -    176.702k in   5.104625s

Comparison:
       fast relation:    47373.2 i/s
       slow relation:    35756.7 i/s - 1.32x  slower
```

This comment was added at 97849deb, but `AssociationProxy` and
`test_triple_equality` was removed at 1644663b. Currently the `===` is
used for `test_decorated_polymorphic_where` that added at #11945.
So I updated "association proxies" to "decorated models".

And also, currently `Core::ClassMethods` appears in the doc.

http://api.rubyonrails.org/classes/ActiveRecord/Core/ClassMethods.html

But it looks like that the methods in the module is not public API.
So I also added `# :nodoc:` to the module.

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.

`StatementCache` doesn't support range conditions. So we need to through
the args to `FinderMethods#find_by` if range value is passed.

`arel_engine` is only used in `raise_record_not_found_exception!` to use
`engine.connection` (and `connection.visitor`) in `arel.where_sql`.

https://github.com/rails/arel/blob/v8.0.0/lib/arel/select_manager.rb#L183

But `klass.connection` will work as expected even if not using
`arel_engine` (described by `test_connection`). So `arel_engine` is no
longer needed.

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

This was added in c24c8852, removed in
b89ffe7f, and then (unintentionally?)
reintroduced in 2d7ae1b0.

`type_condition` should be overwritten by `create_with_value`. So `type`
in `create_with_value` should be a string because `where_values_hash`
keys are converted to string.

Fixes #27600.

Actually, private methods cannot be called with `self.`, so it's not just redundant, it's a bad habit in Ruby

The alternative of #26213.

Currently `find_by` and `where` with AR object return inconsistent
result. This is caused by statement cache does not support AR object.
Passing to finder method to fix the issue.

Fixes #26210.

find and exists?

- After https://github.com/rails/rails/commit/64e5b897ac944a05a33275e3828a3d4047a6b457,
  only :GeneratedAssociationMethods was remaining to be marked as
  private constant, so marked it as well.
- Before:
        >> User.constants(false)
        => [:GeneratedAssociationMethods]
- After:
        >> User.constants(false)
        => []

Raise `ActiveRecord::RangeError` when values that executed are out of range.

If the call to `.define_attribute_methods` actually ends up loading the
schema (*very* hard to do, as it requires the object being created
without `allocate` having been called, but it can be done by manually
calling `initialize` from inside `marshal_load` if you're crazy), the
value of `_default_attributes` will change from that call.

This is not as good a solution as actually hashing both values, but Ruby
doesn't expose that capability other than allocating the array. Unless we were
to do something silly like have a thread local array that is re-used, I don't
see any other way to do this without allocation. This solution may not be
perfect, but it should reasonably avoid collisions to the extent that we need.

The fact that this only includes column names is an oversight.

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.

Rails dropped Ruby 1.9 support, but this comment still true.

A few have been left for aesthetic reasons, but have made a pass
and removed most of them.

Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.

Some case expressions remain, need to think about those ones.