Remove deprecated methods `initialize_schema_migrations_table` and `initialize_internal_metadata_table`

Fix `bin/rails db:setup` and `bin/rails db:test:prepare` create  wrong ar_internal_metadata's data for a test database.

  Before:
  ```
  $ RAILS_ENV=test rails dbconsole
  > SELECT * FROM ar_internal_metadata;
  key|value|created_at|updated_at
  environment|development|2017-09-11 23:14:10.815679|2017-09-11 23:14:10.815679
  ```

  After:
  ```
  $ RAILS_ENV=test rails dbconsole
  > SELECT * FROM ar_internal_metadata;
  key|value|created_at|updated_at
  environment|test|2017-09-11 23:14:10.815679|2017-09-11 23:14:10.815679
  ```

  Fixes #26731.

We already found the longer sequence name, but we could not consider
whether it was the sequence name created by serial type due to missed a
max identifier length limitation. I've addressed the sequence name
consideration to respect the max identifier length.

Fixes #28332.

Currently `AUTO_INCREMENT` is implicitly used in the default primary key
definition. But `AUTO_INCREMENT` is not only used for single column
primary key, but also for composite primary key. In that case,
`auto_increment: true` should be dumped explicitly in the
`db/schema.rb`.

Fixes #30894.

This is the fix for the regression of #29848.

In #29848, I've kept existing select list in the subquery for the count
if ORDER BY is given. But it had accidentally affect to GROUP BY
queries also. It should keep the previous behavior in that case.

Fixes #30886.

* Add missing credit
* Add backticks
* Fix indentation
* Remove trailing spaces

And some minor tweaks.

PostgreSQL 9.1+ introduced range types, and Rails added support for
using this datatype in ActiveRecord. However, the serialization of
`PostgreSQL::OID::Range` was incomplete, because it did not properly
quote the bounds that make up the range. A clear example of this is a
`tsrange`.

Normally, ActiveRecord quotes Date/Time objects to include the
milliseconds. However, the way `PostgreSQL::OID::Range` serialized its
bounds, the milliseconds were dropped. This meant that the value was
incomplete and not equal to the submitted value.

An example of normal timestamps vs. a `tsrange`. Note how the bounds
for the range do not include their milliseconds (they were present in
the ruby Range):

    UPDATE "iterations" SET "updated_at" = $1, "range" = $2 WHERE
    "iterations"."id" = $3
    [["updated_at", "2017-09-23 17:07:01.304864"],
    ["range", "[2017-09-23 00:00:00 UTC,2017-09-23 23:59:59 UTC]"],
    ["id", 1234]]

`PostgreSQL::OID::Range` serialized the range by interpolating a
string for the range, which works for most cases, but does not work
for timestamps:

    def serialize(value)
      if value.is_a?(::Range)
        from = type_cast_single_for_database(value.begin)
        to = type_cast_single_for_database(value.end)
        "[#{from},#{to}#{value.exclude_end? ? ')' : ']'}"
      else
        super
      end
    end

    (byebug) from = type_cast_single_for_database(value.begin)
    2010-01-01 13:30:00 UTC

    (byebug) to = type_cast_single_for_database(value.end)
    2011-02-02 19:30:00 UTC

    (byebug) "[#{from},#{to}#{value.exclude_end? ? ')' : ']'}"
    "[2010-01-01 13:30:00 UTC,2011-02-02 19:30:00 UTC)"

@sgrif (the original implementer for Postgres Range support) provided
some feedback about where the quoting should occur:

  Yeah, quoting at all is definitely wrong here. I'm not sure what I
  was thinking in 02579b56, but what this is doing is definitely in the
  wrong place. It should probably just be returning a range of
  subtype.serialize(value.begin) and subtype.serialize(value.end), and
  letting the adapter handle the rest.

`Postgres::OID::Range` now returns a `Range` object, and
`ActiveRecord::ConnectionAdapters::PostgreSQL::Quoting` can now encode
and quote a `Range`:

    def encode_range(range)
      "[#{type_cast(range.first)},#{type_cast(range.last)}#{range.exclude_end? ? ')' : ']'}"
    end

    ...

    encode_range(range)
    #=> "['2010-01-01 13:30:00.670277','2011-02-02 19:30:00.745125')"

This commit includes tests to make sure the milliseconds are
preserved in `tsrange` and `tstzrange` columns

I do not want to set the expectation that any enumerable object should
behave this way, but this case in particular comes up frequently enough
that I'm caving on this one.

Fixes #30684.

Closes #24190

Fixes #30586.

ActiveRecord associations automatically guess the inverse associations.
But this feature does not work correctly on assoctions for STI.
For example, before this commit

```
class Post < ActiveRecord::Base
  belongs_to :author
end

class SpecialPost < Post; end

class Author < ActiveRecord::Base
  has_many :posts
  has_many :special_posts
end
```

`author.posts.first.author` works correctly, but
`author.special_posts.first.author` does not work correctly.

Add missing backticks
Add missing *
Add missing .

When using a has_many through relation and then summing an attribute
the distinct was not being used. This will ensure that when summing
an attribute, the number is only used once when distinct has been used.

Light grammar fixes, and added a few backticks.

[ci skip]

And make reference to `Relation`.

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.

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

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.

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.

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.

Between 4.2 and 5.0 the behavior of how multiparameter attributes
interact with `_before_type_cast` changed. In 4.2 it returns the
post-type-cast value. After 5.0, it returns the hash that gets sent to
the type. This behavior is correct, but will cause an issue if you then
tried to render that value in an input like `text_field` or
`hidden_field`.

In this case, we want those fields to use the post-type-cast form,
instead of the `_before_type_cast` (the main reason it uses
`_before_type_cast` at all is to avoid losing data when casting a
non-numeric string to integer).

I've opted to modify `came_from_user?` rather than introduce a new
method for this as I want to avoid complicating that contract further,
and technically the multiparameter hash didn't come from assignment, it
was constructed internally by AR.

Close #27888.

This change was introduced by #18109. The intent of that change was to
specifically apply `unscoped`, not to allow all changes to
`current_scope` to affect the join. The idea of allowing `current_scope`
to affect joins is interesting and potentially more consistent, but has
sever problems associated with it. The fact that we're specifically
stripping out joins indicates one such problem (and potentially leads to
invalid queries).

Ultimately it's difficult to reason about what `Posts.joins(:users)`
actually means if it's affected by `User.current_scope`, and it's
difficult to specifically control what does or doesn't get added. If we
were starting from scratch, I don't think I'd have `joins` be affected
by `default_scope` either, but that's too big of a breaking change to
make at this point.

With this change, we no longer apply `current_scope` when bringing in
joins, with the singular exception of the motivating use case which
introduced this bug, which is providing a way to *opt-out* of having the
default scope apply to joins.

Fixes #29338.

Post.where(id: 1).or(Post.where(id: 2)).where(foo: 3).unscope(where: :foo).where_clause.binds.map(&:value)
Would return [2, 3] instead of the expected [1,2]

Abstract boolean serialization has been using 't' and 'f', with MySQL
overriding that to use 1 and 0.

This has the advantage that SQLite natively recognizes 1 and 0 as true
and false, but does not natively recognize 't' and 'f'.

This change in serialization requires a migration of stored boolean data
for SQLite databases, so it's implemented behind a configuration flag
whose default false value is deprecated. The flag itself can be
deprecated in a future version of Rails.  While loaded models will give
the correct result for boolean columns without migrating old data,
where() clauses will interact incorrectly with old data.

While working in this area, also change the abstract adapter to use
`"TRUE"` and `"FALSE"` as quoted values and `true` and `false` for
unquoted.  These are supported by PostreSQL, and MySQL remains
overriden.