Follow up of #24203.

Since b644964b `ActiveRecord::Relation` includes `Enumerable` so it is
enough to call `super` simply.

Follow up of e7381d28.

The `select` in `QueryMethods` is also an enumerable method.
Enumerable methods with block should delegate to `records` on
`CollectionProxy`, not `scope`.

Fixes #28348.

Since 67fba0cf `SchemaMigration` model was extracted.
Use `SchemaMigration.table_name` instead.

In #27674 we changed the migration generator to generate migrations at
the path defined in `Rails.application.config.paths` however the code
checked for the presence of the `Rails` constant but not the
`Rails.application` method which caused problems when using Active
Record and generators outside of the context of a Rails application.

Fixes #28325.

Use `SchemaMigration.all_versions` instead of
`SchemaMigration.all.map(&:version)` to avoid to instantiate AR objects.

Fixes #28285.

Simply use `SchemaMigration.table_name` instead.

Related #25174.

`db:schema:load` doesn't work with subdirectories like previous
`db:migrate:status`. `Migrator.migration_files` should be used in
`assume_migrated_upto_version` to fix the issue.

`db:migrate` supports subdirectories and have a test.

https://github.com/rails/rails/blob/v5.1.0.beta1/activerecord/test/cases/migrator_test.rb#L78-L85

But `db:migrate:status` doesn't work with subdirectories. It is due to
`Dir.foreach(path)` is not the same with `Dir["#{path}/**/[0-9]*_*.rb"]`.

I extracted `migration_files` and sharing it in the both to fix the
issue. And added tests for `db:migrate:status`.

Sharing `options` causes some unexpected behavior. If `limit: 2` is
specified, this means that 2 bytes integer for a reference id column and
2 chars string for a reference type column. Another example, if
`unsigned: true` is specified, this means that unsigned integer for a
reference id column, but a invalid option for a reference type column.
So `options` should not be shared with a reference type column.

Reflections only use their own information to create a `join_keys`
object.  This means that we can call `join_keys` on a reflection object
and have it be context-free.

Scopes can only ever be *not* reflection objects when they are passed in
to the Reflection constructor.  Given this fact, we can eliminate is_a
checks and an intermediate array object by just asking the reflection
object for join scopes.

I don't think we actually need this parameter anymore.  Nobody seems to
be using it.

I incorrectly changed behavior of `dup`. Reading the original issue I
thought that `dup` should retain the original contents of the record
and it's associations but it is in fact supposed to be a copy as if a
record had been reinitialized.

This reverts commit ca8c21df.

In Rails 3.2 dupping a `CollectionProxy` would dup it's `load_target` as
well. That functionality has been broken since the release of Rails 4.0.
I hit this in an application upgrade and wondered why duplicating a
CollectionProxy and assigning it to a variable stopped working.

When calling `dup` on a `CollectionProxy` only the owner (ex.
topic) was getting duplicated and the `load_target` would remain in tact
with it's original object ID. Dupping the `load_target` is useful for performing
a logging operation after records have been destroyed in a method.

For example:

```
def transfer_operation
  saved_replies = topic.replies

  topic.replies.clear

  saved_replies.each do |reply|
    user.update_replies_count!
  end
end
```

This change adds a `initialize_dup` method that performs a `deep_dup` on
the `@associatiation` so that the `load_target` is dupped as well.

Fixes #17117

`valid_type?` is used in schema dumper to determine if a type is
supported. So if `valid_type?(:foobar)` is true, it means that schema
dumper is allowed to create `t.foobar`. But it doesn't work. I think
that `valid_type?` should accept only supported types.

https://github.com/rails/rails/blob/v5.1.0.beta1/activerecord/lib/active_record/schema_dumper.rb#L135-L142

```ruby
  columns.each do |column|
    raise StandardError, "Unknown type '#{column.sql_type}' for column '#{column.name}'" unless @connection.valid_type?(column.type)
    next if column.name == pk
    type, colspec = @connection.column_spec(column)
    tbl.print "    t.#{type} #{column.name.inspect}"
    tbl.print ", #{format_colspec(colspec)}" if colspec.present?
    tbl.puts
  end
```

Follow up of #26266.

The default type of `primary_key` and `references` were changed to
`bigint` since #26266. But `create_join_table` column type is still
`integer`. It should respect `references` column type.

`tables` returns only tables now.

Actually `index_name_length` depend on `max_identifier_length`, not
always 63.

`supports_migrations?` was added at 4160b518 to determine if schema
statements (`create_table`, `drop_table`, etc) are implemented in the
adapter. But all tested databases has been supported migrations since
a4fc93c3 at least.

When a grouped calculation contains a having clause that references a
selected value, we need to include that selected value in the query.

Postgres doesn't support referencing a selected value in a having
clause, but other databases do; we can skip the test on the pg adapter
but run it for the others.

This was fixed before in 9a298a16, but
the test coverage was lost in 5a05207d.
The fix regressed in 6311975f and was
removed in 97d46c17.

If the `index` exceeds a `limit`, simply return an empty result without
querying the database.

`select_values` is a local variable defined at previous line.
`select_values += select_values` is totally useless.

`valid_type?` should return true if a type exists in
`native_database_types` at least.

https://github.com/rails/rails/blob/v5.1.0.beta1/activerecord/lib/active_record/schema_dumper.rb#L136

Currently `change_column` cannot drop default if `null: false` is
specified at the same time. This change fixes the issue.

```ruby
  # cannot drop default
  change_column "tests", "contributor", :boolean, default: nil, null: false

  # we need the following workaround currently
  change_column "tests", "contributor", :boolean, null: false
  change_column "tests", "contributor", :boolean, default: nil
```

Closes #26582

`DISTINCT` clause is applied inside aggregate function by
`operation_over_aggregate_column` if needed. Unneeded outside aggregate
function.

```ruby
  # Before
  author.unique_categorized_posts.count
  # => SELECT DISTINCT COUNT(DISTINCT "posts"."id") FROM "posts" INNER JOIN "categorizations" ON "posts"."id" = "categorizations"."post_id" WHERE "categorizations"."author_id" = ?  [["author_id", 2]]

  # After
  author.unique_categorized_posts.count
  # => SELECT COUNT(DISTINCT "posts"."id") FROM "posts" INNER JOIN "categorizations" ON "posts"."id" = "categorizations"."post_id" WHERE "categorizations"."author_id" = ?  [["author_id", 2]]
```

Closes #27615

Since using a `ActiveSupport::Deprecation::DeprecatedConstantProxy`
would prevent people from inheriting this class and extending it
from the `ActiveSupport::HashWithIndifferentAccess` one would break
the ancestors chain, that's the best option we have here.

Remove styling from `true` and `false`.

Originally `quoted_id` was used in legacy quoting mechanism. Now we use
type casting mechanism for that. Let's deprecate `quoted_id`.

Fixes #26556.