Add Active Record numericality validator with support for casting
floats using a database columns' precision value.

Add ActiveRecord::Relation#cache_key_with_version. This method will be
used by ActionController::ConditionalGet to ensure that when collection
cache versioning is enabled, requests using ConditionalGet don't return
the same ETag header after a collection is modified.

Prior to the introduction of collection cache versioning in
4f2ac80d, all collection cache keys
included a version. However, with cache versioning enabled, collection
cache keys remain constant. In turn, ETag headers remain constant,
rendering them ineffective.

This commit takes the cache_key_with_version method used for individual
Active Record objects (from aa8749eb),
and adds it to collections.

Fixes https://github.com/rails/rails/issues/28827.

The steps to reproduce are as follows:

git clone git@github.com:bbuchalter/rails-issue-28827.git
cd rails-issue-28827
bundle install
bin/rails db:create

Observe that we create two databases when invoking db:create: development and test. Now observe what happens when we invoke our drop command while using DATABASE_URL.

DATABASE_URL=sqlite3://$(pwd)/db/database_url.sqlite3 bin/rails db:create

As expected, the development environment now uses the DATABASE_URL. What is unexpected is that the test environment does not.

It's unclear what the expected behavior should be in this case, but the cause of it is this: https://github.com/rails/rails/blob/9f2c74eda07ea5a9e4e624d5575a717714088dbf/activerecord/lib/active_record/tasks/database_tasks.rb#L494

Because of each_local_configuration, there seems to be no way invoke these database rake on only the development environment to ensure DATABASE_URL is respected.

The smallest scope of change I can think to make would be to conditionalize this behavior so it does not get applied when DATABASE_URL is present.

`name` is used by Rails to find the configuration by connection
specification name, but database adapters don't need to use `name` in
order to establish a connection. This is part of our work to separate
what the database needs to connect (the configuration hash) and the
what Rails needs to find connections (everything else).
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

- I'm hoping to get this change accepted even though this flag was
  introduced years ago in 6576f735

  My use case is the following:

  We were never enforcing belongs to association and we have a lot
  of models that implicitely declare an association as optional.
  We are now changing all our models to make associations required
  by default.
  Since we have a lot of models (more than 1000), I'd like to
  progressively enable them to use the `belongs_to_required_by_default`
  flag.

  The problem is that this flag is a mattr_accessor and doesn't to be
  set per model. We basically need to modify all our models (which
  could take years) before being able to modify the global flag.

  I'd like to change this flag to a class_attribute to solve the
  issue.

The `connection_config` method returns a `Hash`, but since we're moving
toward a place where we're using `DatabaseConfiguration::DatabaseConfig`
objects everywhere, we're introducing a new method here to replace it
called `connection_db_config`.
Co-authored-by: Neileencodes <eileencodes@gmail.com>

A querystring value should be allowed to include an equal sign `=`.

This is necessary to support passing `options` for a PostgresSQL connection.

```

development:
  url: postgresql://localhost/railsdevapp_development?options=-cmysetting.debug=on
```

Before this PR, attempting to start the rails process with that configuration would result in an error:

```
> bundle exec rails console
Traceback (most recent call last):
	49: from bin/rails:4:in `<main>'
	48: from bin/rails:4:in `require'
...
	 1: from /rails/activerecord/lib/active_record/database_configurations/connection_url_resolver.rb:58:in `query_hash'
/rails/activerecord/lib/active_record/database_configurations/connection_url_resolver.rb:58:in `[]': invalid number of elements (3 for 1..2) (ArgumentError)
```

After this PR, rails can properly parse the configuration:

```
> bundle exec rails console
Loading development environment (Rails 6.1.0.alpha)
2.6.5 :001 > ActiveRecord::Base.connection.select_all("show mysetting.debug").to_a
   (0.4ms)  show mysetting.debug
 => [{"mysetting.debug"=>"on"}]
```

Applying `includes` and `joins` to a relation that selected additional
database fields would cause those additional fields not to be included
in the results even though they were queried from the database:

    posts = Post.select('1 as other').includes(:tbl).joins(:tbl)

    posts.to_sql.include?('1 as other')       #=> true
    posts.first.attributes.include?('other')  #=> false

This commit includes these additionally selected fields in the
instantiated results.

The `database` kwarg in `connected_to` has resulted in a lot of bug
reports that are trying to use it for sharding when that's not the
intent of the key. After considering where the database kwarg is used in
tests and thinking about usecases for it, we've determined it should be
removed.

There are plans to add sharding support and in the mean time the
database kwarg isn't the right solution for that. Applications that need
to create new connections can use establish_connection or connects_to.
Since the database key causes new connections to be established on every
call, that causes bugs if connected_to with a database kwarg is used
during a request or for any connection that's not a one-off.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

We have these two objects, `ConnectionAdapters::Resolver` and
`DatabaseConfiguratons` that implement a lot of the same logic. One of
them is used for configurations defined in `config/database.yml` and the
other is used when passing raw configurations `String` or `Hash` objects
into methods like `establish_connection`.

Over time these two have diverged a bit. In the interest of less code
complexity, and more consistency for users this commit brings them back
together.

* Remove `Resolver` altogether and replace its primary method with
  `DatabaseConfigurations#resolve`.

* Move `resolve_pool_config` over to the `ConnectionPool` alongside the code
  that uses it.

Forgot to add a changelog when this was merged in #37266.

We deprecated `to_h` in https://github.com/rails/rails/pull/37231, and
this commit adds the appropriate `CHANGELOG` entry!

Previously in some places we used symbol keys, and in some places we used
string keys. That made it pretty confusing to figure out in a particular
place what type of configuration object you were working with.

Now internally, all configuration hashes are keyed by symbols and
converted to such on the way in.

A few exceptions:

- `DatabaseConfigurations#to_h` still returns strings for backward compatibility
- Same for `legacy_hash`
- `default_hash` previously could return strings, but the associated
  comment mentions it returns symbol-key `Hash` and now it always does

Because this is a change in behavior, a few method renames have happened:

- `DatabaseConfig#config` is now `DatabaseConfig#configuration_hash` and returns a symbol-key `Hash`
- `ConnectionSpecification#config` is now `ConnectionSpecification#underlying_configuration_hash` and returns the `Hash` of the underlying `DatabaseConfig`
- `DatabaseConfig#config` was added back, returns `String`-keys for backward compatibility, and is deprecated in favor of the new `configuration_hash`
Co-authored-by: Neileencodes <eileencodes@gmail.com>

Before this patch, column names could only be passed as a positional
argument when no other options were supplied:

    remove_index :reports, :report_id

Passing column names positionally along with other options would fail:

    remove_index :reports, :report_id, unique: true
    # => ArgumentError: wrong number of arguments (given 3, expected 1..2)

In 3809c80c, adding an index with a
name that's already in use was changed from an error to a warning, to
allow other statements in the same migration to complete successfully.

In 55d0d57b this decision was reversed,
but instead of allowing the statement to execute and raise an adapter-
specific error as it did before, an `ArgumentError` was raised instead.

This interferes with a legitimate use case: on MySQL, it's possible to
drop an index and add another one with the same name in a single `ALTER`
statement. Right now an `ArgumentError` is raised when trying to do so,
even though the resulting statement would execute successfully.

There's no corresponding `ArgumentError` raised when attempting to add a
duplicate column, so I think we can safely remove the check and allow
the adapter to raise its own error about duplicate indexes again.

The `InsertAll` class currently calls `exec_query`, which doesn't give
the query cache enough information to know that it needs to be cleared.

By adding an `exec_insert_all` method that calls `exec_query` internally
we can configure the query cache to clear when that method is called.

If a user is using the middleware for swapping database connections and
manually calling `connected_to` in a controller/model/etc without
calling `while_preventing_writes(false)` there is potential for a race
condition where writes will be blocked.

While the user could _just_ call `while_preventing_writes` in the same
place they call `connected_to` this would mean that all cases need to
call two methods.

This PR changes `connected_to` to call `while_preventing_writes`
directly. By default we'll assume you don't want to prevent writes, but
if called with `connected_to(role: :writing, prevent_writes: true)` or
from the middleware (which calls `connected_to` this way) the writes
will be blocked.

For replicas, apps should use readonly users to enforce not writing
rather than `while_preventing_writes` directly.

Should fix the remaining issues in
https://github.com/rails/rails/issues/36830

in the edge case when the query is terminated by MySQL server during filesort.
See https://bugs.mysql.com/bug.php?id=96537 for more details.

To continue taking non-deterministic result, use `.take` / `.take!`
instead.

Make sure primary keys with non-integer types can be correctly type
casted in through reflections.

Currently, string joins are always applied as last joins part, and Arel
join nodes are always applied as leading joins part (since #36304), it
makes people struggled to preserve user supplied joins order.

To mitigate this problem, preserve the order of string joins and Arel
join nodes either before or after of association joins.

Fixes #36761.
Fixes #34328.
Fixes #24281.
Fixes #12953.

Previously matches_regex was only availble on PostgreSql, this will enable it for MySql

Usage example:

    users = User.arel_table;
    users = User.arel_table; User.where(users[:email].matches_regexp('(.*)\@gmail.com'))

Update activerecord/test/cases/arel/visitors/mysql_test.rb
Co-Authored-By: NRyuta Kamizono <kamipo@gmail.com>

Allow specifying what fixtures can be ignored by setting
`ignore` in fixtures YAML file:

    # users.yml
    _fixture:
      ignore:
        - base

    base: &base
      admin: false
      introduction: "This is a default description"

    admin:
      <<: *base
      admin: true

    visitor:
      <<: *base

In the above example, "base" fixture will be ignored when creating
users fixture. This is helpful when you want to inherit attributes
and it makes your fixtures more "DRY".

This commit adds a feature which allows separate database ENV variables
to be defined for each spec in a 3-tier config. The names for the
environment variables will be `#{name.upcase}_DATABASE_URL`

This commit also introduces a change in behavior around handling of
`DATABASE_URL`. Instead of using `DATABASE_URL` to change _all_ specs
in a multi-database configuration, it will now only affect the `primary`
connection.

Ruby 2.7 introduces beginless ranges (..value and ...value) and as with
endless ranges we can turn these into inequalities, enabling expressions
such as

    Order.where(created_at: ..1.year.ago)
    User.where(karma: ...0)

Ref https://github.com/rails/rails/pull/36621#discussion_r301208961

When a enum element contains the prefix 'not_'. I warns to users
to be aware of this new feature.

Example code:
    class Foo < ActiveRecord::Base
      enum status: [:sent, :not_sent]
    end