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.

This commit will be squished into f4fbdb1b after maintainer's review.

The `_trigger_update_callback` and `_trigger_destroy_callback`
attributes were added in 9252da96 to
avoid running transactional callbacks when an attempt to modify a record
fails inside a transaction due to the record being invalid, for example.

However the values weren't being reset between transactions, which meant
they leaked from one transaction to another and caused false positives
where unsuccessful modifications still triggered callbacks. Clearing
them when a transaction commits or is rolled back fixes the problem.

If `AR::Enum` is used for boolean field, it would be not expected
behavior for us.

fixes #38075

Problem:

In case of using boolean for enum, we can set with string (hash key)
to instance, but we cannot set with actual value (hash value).

```ruby
class Post < ActiveRecord::Base
  enum status: { enabled: true, disabled: false }
end

post.status = 'enabled'
post.status # 'enabled'

post.status = true
post.status # 'enabled'

post.status = 'disabled'
post.status # 'disabled'

post.status = false
post.status # nil (This is not expected behavior)
```

After looking into `AR::Enum::EnumType#cast`, I found that `blank?`
method converts from false value to nil (it seems it may not intentional behavior).

In this patch, I improved that if it defines enum with boolean,
it returns reasonable behavior.

The regular expression did not match CREATE TABLE statements printed out by AWS Aurora MySQL 5.6 instances, because they lack the required space at that position.

Activerecord ruby 2.7 warnings 6 0 stable batch 2

This adds `:declare`, `:fetch`, `:move`, and `:close` to allowed queries
when `while_preventing_writes` is set. I didn't support `:open` because
AFAICT `:declar` implcitly opens a cursor and all of my attempts to
write `@connection.execute("OPEN cur_ex")` threw a syntax error on
`OPEN`. It seems like open isn't supported with the client.

Fixes: #37960

We want to introduce an object-based DSL for building and modifying
configuration objects. As part of that we want to make sure that users
don't think they can modify configuration_hash values and have them
change the configuration. For that reason we're going to freeze the
Hash here, and have modified places in tests where we were modifying
these hashes.

The commit here also adds a test for the Test Databases and in that work
we found that we were calling `Rails.env` and Active Record doesn't load
Rails.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

These tests weren't calling assert, so if the execute didn't raise but
also didn't return anything it would be a broken test that never fails.
We need to always add an assertion so we know what the expected behavior
is.

Related #36456.

I grepped the code base by `git grep -n 'connection_id: '` then I found
extra `connection_id: object_id` which is added at #20818 but unused.

Actually the `connection_id: object_id` is not a connection's object_id
but a connection_handler's object_id, it is very confusing.

Since the `:connection_id` in an internal instrument is not used, we can
just remove the incorrect information.

`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.

This method in test has a confusing name that also is the same as a
method with a different behavior on `ActiveRecord::Base` so we're just
renaming it to avoid confusion between the two!
Co-authored-by: Neileencodes <eileencodes@gmail.com>

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>

- #37798 had to be reverted because a new flakyness appeared ([see
  CI build](https://buildkite.com/rails/rails/builds/65467#efaa1dd5-aaf4-43a1-a204-d1c42abf614d))

  This failure isn't related to the change itself.
  If you apply this diff, the test will some time to time fail.
  Even without my changes.

  ```diff
  diff --git a/activerecord/test/cases/transactions_test.rb b/activerecord/test/cases/transactions_test.rb
index b5c1cac3d9..09fe0ddd7f 100644
--- a/activerecord/test/cases/transactions_test.rb
+++ b/activerecord/test/cases/transactions_test.rb
@@ -1127,7 +1127,6 @@ def test_no_automatic_savepoint_for_inner_transaction
   end
 end if Topic.connection.supports_savepoints?

-if ActiveRecord::Base.connection.supports_transaction_isolation?
   class ConcurrentTransactionTest < TransactionTest
     # This will cause transactions to overlap and fail unless they are performed on
     # separate database connections.
@@ -1198,4 +1197,3 @@ def test_transaction_isolation__read_committed
       assert_equal original_salary, Developer.find(1).salary
     end
   end
-end
  ```

  SQlite3 isn't safe to run in a multi threaded environment unless
  sqlite is compiled with a special flag which isn't our case.
  Ref https://www.sqlite.org/threadsafe.html

This reverts commit 25daafbc.

This reverts commit b4ab1f19, reversing
changes made to 9926fd86.

This is causing CI to fail about 50% of the time, and can be reproduced
locally 100% of the time on my machine.

Ex failing build https://buildkite.com/rails/rails/builds/65467#efaa1dd5-aaf4-43a1-a204-d1c42abf614d

Error:

```
SQLite3::BusyException: database is locked (ActiveRecord::StatementInvalid)
```

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"}]
```

- SQlite allow database to be specified as URL (given that URI filename
  interpretation was turned on on the connection.)

  This commit is necessary for the read_uncommitted transaction
  feature because SQLite doesn't allow to enable the shared-cache mode
  if the database name is `:memory:`. It has to be a URI (`file::memory`)

  Ref https://www.sqlite.org/sharedcache.html#shared_cache_and_in_memory_databases

- ### Use case

  I'd like to be able to see changes made by a connection writer
  within a connection reader before the writer transaction commits
  (aka `read_uncommitted` transaction isolation level).

  ```ruby
  conn1.transaction do
    Dog.create(name: 'Fido')
    conn2.transaction do
      Dog.find(name: 'Fido') # -> Can't see the dog untill conn1 commits the transaction
    end
  end
  ```

  Other adapters in Rails (mysql, postgres) already supports multiple
  types of isolated db transaction.
  SQLite doesn't support the 4 main ones but it supports
  `read_uncommitted` and `serializable` (the default one when opening
  a transaction)

  ### Solution

  This PR allow developers to open a `read_uncommitted` transaction by
  setting the PRAGMA `read_uncommitted` to true for the duration
  of the transaction. That PRAGMA can only be enabled if the SQLite
  connection was established with the [shared-cache mode](https://www.sqlite.org/sharedcache.html)

  This feature can also benefit the framework and we could potentially
  get rid of the `setup_shared_connection_pool` inside tests which
  was a solution in the context of a multi-db app so that the reader
  can see stuff from the open transaction writer but has some [caveats](https://github.com/rails/rails/issues/37765#event-2828609021).

  ### Edge case

  Shared-cache mode can be enabled for in memory database as well,
  however for backward compatibility reasons, SQLite only allows
  to set the shared-cache mode if the database name is a URI.
  It won't allow it if the database name is `:memory`; it has to be
  changed to `file::memory` instead.

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>

If a spec name was provided without an env name, config_for would return
the first config that matched the spec, regardless of environment name.

Now configs_for will return the database config that matches the
default env and requested spec name.

Additionally this commit has moved the default env call into a method
because I'm tired of typing so many lines every single time.

We considered either returning all configs that match that spec name or
raising an error if only spec was passed, but this change has the least
impact on current behavior and matches Active Record's assumptions: that
if you ask for configs it will always consider the current environment.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

Reference:
https://buildkite.com/rails/rails/builds/65255#d4ce371f-75e6-4f82-98e8-d2a0d9f791f5/1005-1016

Testing for sqlite3 makes an extra db file `primary.sqlite3` as below.
```
$ bundle exec rake test:sqlite3
(snip)
$ git status
On branch test
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        db/
```

- ### Problem

  Connection pools are not properly shared. A replica can't see the
  data in the open transaction on the writing connection.
  ```ruby
  Dog.create!(name: 'bilou')

  AnimalsBase.connected_to(role: :reading) do
    Dog.find_by(name: 'bilou') # No result
  end
  ```

  The reason of this bug is because when test starts, we iterate
  over `AR::Base.connection_handlers` which only contains the `writing`
  handler since models haven't been loaded (app isn't eagerloaded
  test env).

  ### Solution

  Share connection pools as soon as a connection is established
  by creating a subcriber.

- ### Problem

  If one wants to use ActiveRecord::TestFixtures it is mandatory for
  the test suite to inherit from `ActiveSupport::TestCase`.
  TestFixtures makes use of specific method from AS::TestCase
  (`file_fixture_path` and `method_name`).

  ### Solution

  This PR fixes that by not making use of method_name and file_fixture_path.

There is an unused connection handler in a test and an extra
connection handler is made, so testing for sqlite3 makes an empty db
file as below.

```
$ bundle exec rake test:sqlite3
(snip)
$ git status
On branch test
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        db/
```

Currently, when checking that the collection has been loaded, only the first
record is checked. In specific scenarios, if a record is fetched via an `after_initialize`
hook, there is a chance that the first record has been loaded, but other records in the
collection have not.

In order to successfully short circuit the fetching of data, we need to verify that
all of the records in the collection have been loaded.

* Create test for edge case
* Move `reset_callbacks` method to `cases/helper`, since it has been defined in multiple
  locations.

Closes #37730

JRuby can't support processes, and in memory db can't support changing
the handlers/connections during the test.

If `in_memory_db?`, connecting to database on new handler is no schema
and fixture loaded.

Closes #37734.

It shouldn't matter whether or not QC is enabled, inserts, updates, etc
(anything that modifies the state of the DB) should invalidate the
cache.