GROUP BY with virtual count attribute is invalid for almost all
databases, but it is valid for PostgreSQL, and it had worked until Rails
5.2.2, so it is a regression for Rails 5.2.3 (caused by 311f0011).

I can't find perfectly solution for fixing this for now, but I would not
like to break existing apps, so I decided to allow referencing virtual
count attribute in ORDER BY clause when GROUP BY aggrigation (it partly
revert the effect of 311f0011) to fix the regression #36022.

Fixes #36022.

Fix typo initialzer -> initializer

[ci skip]

Delete method definition in rails that is compatible with ruby defini…

Tests are also only on the `Time` class

Update doc forgetting to erase when moved

Update guide `Date` class to `Time` class and defined file

Update guide correction omission

Ref: bcf370d6, 06ab7b27.

Remove unused `Arel::Attributes.for`

Delete 'ruby' in the description of the method defined in rails [skip ci]

`Arel::Attributes.for` is no longer used since https://github.com/rails/arel/pull/196.

No allocation `Arel::Visitors::ToSql#visit`

Each `visit o, collector` allocates one extra array due to
receiving args by splat array.

https://github.com/rails/rails/blob/2c3332cc4c0fa77dbe2e13e8a792f80fbd8f4ad3/activerecord/lib/arel/visitors/visitor.rb#L27-L29

Currently 1,000 times `User.where(id: 1).to_sql` allocates 13,000
arrays in `visitor.accept`. This avoids receiving args by splat array,
it makes `visitor.accept` no array allocation.

```ruby
ObjectSpace::AllocationTracer.setup(%i{path line type})

pp ObjectSpace::AllocationTracer.trace {
  1_000.times { User.where(id: 1).to_sql }
}.select { |k, _| k[2] == :T_ARRAY && k[0].end_with?("visitor.rb", "to_sql.rb") }
```

Before (2c3332cc):

```
{["~/rails/activerecord/lib/arel/visitors/to_sql.rb",
  18,
  :T_ARRAY]=>[1000, 0, 0, 0, 0, 0],
 ["~/rails/activerecord/lib/active_record/connection_adapters/determine_if_preparable_visitor.rb",
  11,
  :T_ARRAY]=>[1000, 0, 0, 0, 0, 0],
 ["~/rails/activerecord/lib/arel/visitors/visitor.rb",
  12,
  :T_ARRAY]=>[1000, 0, 0, 0, 0, 0],
 ["~/rails/activerecord/lib/arel/visitors/to_sql.rb",
  788,
  :T_ARRAY]=>[3000, 0, 0, 0, 0, 0],
 ["~/rails/activerecord/lib/arel/visitors/to_sql.rb",
  794,
  :T_ARRAY]=>[3000, 0, 0, 0, 0, 0],
 ["~/rails/activerecord/lib/arel/visitors/to_sql.rb",
  156,
  :T_ARRAY]=>[1000, 0, 0, 0, 0, 0],
 ["~/rails/activerecord/lib/arel/visitors/to_sql.rb",
  443,
  :T_ARRAY]=>[1000, 0, 0, 0, 0, 0],
 ["~/rails/activerecord/lib/arel/visitors/to_sql.rb",
  603,
  :T_ARRAY]=>[1000, 0, 0, 0, 0, 0],
 ["~/rails/activerecord/lib/arel/visitors/to_sql.rb",
  611,
  :T_ARRAY]=>[1000, 0, 0, 0, 0, 0]}
```

After (this change):

```
{}
```

Tables in tests are not always empty so `klass.first` does not always
find last created record.

Fixes #36479.

https://buildkite.com/rails/rails/builds/61744#f12cc6cf-7458-4131-917a-9735615f6259/999-1010

Move while_preventing_writes from conn to handler

If we put the `while_preventing_writes` on the connection then the
middleware that sends reads to the primary and ensures they can't write
will not work. The `while_preventing_writes` will only be applied to the
connection which it's called on - which in the case of the middleware is
Ar::Base.

This worked fine if you called it directly like
`OtherDbConn.connection.while_preventing_writes` but Rails didn't have a
way of knowing you wanted to call it on all the connections.

The change here moves the `while_preventing_writes` method from the
connection to the handler so that it can block writes to all queries for
that handler. This will apply to all the connections associated with
that handler.

Update multi-db docs

* Add note about schema cache
* Add note about opening too many connections
* Improve headers in caveats section

Move SchemaMigration to migration_context

This PR moves the `schema_migration` to `migration_context` so that we
can access the `schema_migration` per connection.

This does not change behavior of the SchemaMigration if you are using
one database. This also does not change behavior of any public APIs.
`Migrator` is private as is `MigrationContext` so we can change these as
needed.

We now need to pass a `schema_migration` to `Migrator` so that we can
run migrations on the right connection outside the context of a rake
task.

The bugs this fixes were discovered while debugging the issues around
the SchemaCache on initialization with multiple database. It was clear
that `get_all_versions` wouldn't work without these changes outside the
context of a rake task (because in the rake task we establish a
connection and change AR::Base.connection to the db we're running on).

Because the `SchemaCache` relies on the `SchemaMigration` information we
need to make sure we store it per-connection rather than on
ActiveRecord::Base.

[Eileen M. Uchitelle & Aaron Patterson]

[ci skip] Update docs as `remove_column` can be reversed

As `remove_column` can be reversed when a type is provided this example
was not accurate anymore.

Allocation on demand in transactions

Currently 1,000 transactions creates 10,000 objects regardless whether
it is necessary or not.

This makes allocation on demand in transactions, now 1,000 transactions
creates required 5,000 objects only by default.

```ruby
ObjectSpace::AllocationTracer.setup(%i{path line type})

pp ObjectSpace::AllocationTracer.trace {
  1_000.times { User.create }
}.select { |k, _| k[0].end_with?("transaction.rb") }
```

Before (95d038f0):

```
{["~/rails/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb",
  209,
  :T_HASH]=>[1000, 0, 715, 0, 1, 0],
 ["~/rails/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb",
  210,
  :T_OBJECT]=>[1000, 0, 715, 0, 1, 0],
 ["~/rails/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb",
  210,
  :T_HASH]=>[1000, 0, 715, 0, 1, 0],
 ["~/rails/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb",
  80,
  :T_OBJECT]=>[1000, 0, 715, 0, 1, 0],
 ["~/rails/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb",
  8,
  :T_ARRAY]=>[1000, 0, 715, 0, 1, 0],
 ["~/rails/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb",
  81,
  :T_ARRAY]=>[1000, 0, 715, 0, 1, 0],
 ["~/rails/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb",
  289,
  :T_STRING]=>[1000, 0, 714, 0, 1, 0],
 ["~/rails/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb",
  116,
  :T_ARRAY]=>[1000, 0, 714, 0, 1, 0],
 ["~/rails/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb",
  120,
  :T_ARRAY]=>[1000, 0, 714, 0, 1, 0],
 ["~/rails/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb",
  121,
  :T_HASH]=>[1000, 0, 714, 0, 1, 0]}
```

After (this change):

```
{["~/rails/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb",
  213,
  :T_HASH]=>[1000, 0, 739, 0, 1, 0],
 ["~/rails/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb",
  214,
  :T_OBJECT]=>[1000, 0, 739, 0, 1, 0],
 ["~/rails/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb",
  214,
  :T_HASH]=>[1000, 0, 739, 0, 1, 0],
 ["~/rails/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb",
  81,
  :T_OBJECT]=>[1000, 0, 739, 0, 1, 0],
 ["~/rails/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb",
  304,
  :T_STRING]=>[1000, 0, 738, 0, 1, 0]}
```

[ci skip] Use default path in button_to documentation

Fix programmatic clicks with data-remote

This is really a nit pick, but as this is the framework's documentation
I think it should follow standards as many times as possible to avoid
confusion in new users.

If we were using `resources :articles` in routes. which is what scaffold
adds, the generated helper would be `new_article_path` instead of
`new_articles_path`.

* Make ActiveRecord `ConnectionPool.connections` thread-safe.

ConnectionPool documentation is clear on the need to synchronize
access to @connections but also states that public methods do not
require synchronization. Existing code exposed @connections
directly via attr_reader. The fix uses synchronize() to lock
@connections then returns a copy to the caller using Array.dup().

Includes comments on the connections method that thread-safe access
to the connections array does not imply thread-safety of accessing
methods on the actual connections.

Adds a test-case that modifies the pool using a supported method
in one thread  while a second thread accesses pool.connections.
The test fails without this patch.

Fixes #36465.

* Update activerecord/test/cases/connection_pool_test.rb

[jeffdoering + Rafael Mendonça França]

images/getting_started: Update screenshot for missing action

Introduce ActionView::Component

"schema_migrations" table may be hard dropped before, so the reset
migration version should be done in ensure block.

https://buildkite.com/rails/rails/builds/61697#18d6f3ac-2257-4f4b-8efc-4010464c4d9a/999-1011

https://buildkite.com/rails/rails/builds/61695#373bb1a7-677f-49ec-95e7-a92467fefd60/1076-1084

"schema_migrations" is hard dropped by some existing tests, so testing
migration in using transactional tests may cause implicit creation and
rollback "schema_migrations" table, it makes migration tests flaky.

https://buildkite.com/rails/rails/builds/61692#42383249-30be-4508-b1fb-a7bb27600c8e/999-1010
https://buildkite.com/rails/rails/builds/61694#6e462ad3-41d8-4e26-95ce-728495b0ac64/999-1010

Enable `Layout/EmptyLinesAroundAccessModifier` cop

`table_exists?` is already exist in `ModelSchema`.

https://github.com/rails/rails/blob/5cab344494c340ea82a35b46efa06b94f0b7730b/activerecord/lib/active_record/model_schema.rb#L339-L341

Since 5cab3444, `drop_table` clears schema cache.