We only need action and method so pass them explicitly instead of
merging the hash with HTML options.

Fixed passing of delete method on button_to tag, creating wrong form csrf token

Fix `assert_in_delta` test failure

Fix NoMethodError preparable for Arel::Visitors::PostgreSQL

Add test cases about MySQL ORDER BY FIELD()

Fix typographical error

Remove `alias exec_without_stmt exec_query`

Improve the performance of string xor operation

Adding test to verify the last week when the year is leap

Reduce `attribute.to_s`

Remove unused parameter from method

Match test name to test (typo)

Add a note about downcasing submit tag

This is a notable change since this will cause confusing test failures for tests relying on the old naming scheme.

Show correct return types for examples

Fixes #23524

Why are we here? Where did we come from? Where are we going... in 5 minutes?

These questions are not answered in this documentation. Instead collection
caching is better clarified. How it works, how it can share caches with
individual templates.

Yo dawg, we so explicit if we were a music track, yo' iPhone's Music app would put
an E next to it.

*drops mic*

Get it? ( ͡° ͜ʖ ͡°)

use method provided by minitest

Fixed typo

The process of converting `Test` to `String` is already defined in minitest.
I think it is better to use that for the consistency of output content.

ref: https://github.com/seattlerb/minitest/blob/master/lib/minitest/test.rb#L261..L267

Improve CHANGELOG for https://github.com/rails/rails/pull/17043 [ci skip]

Mutating the result of Relation#to_a should not affect the relation

Make collection caching explicit.

Augments the collection caching with some instrumentation that's logged.

For collections that have been cached like:

```ruby
<%= render partial: 'notifications/notification', collection: @notifications, cached: true %>
```

We'll output a line showing how many cache hits we had when rendering it:

```
  Rendered collection of notifications/_notification.html.erb [0 / 100 cache hits] (3396.5ms)
```

Clarifying this separation and enforcing relation immutability is the
culmination of the previous efforts to remove the mutator method
delegations.

Reevaluating the log output generated from this instrumentation,
we've found that it wasn't all that useful in practice.

```
Caches multi read:
- views/david/2/4184ab71db6849621a4d8820fcd2c0ad
- views/david/2/4184ab71db6849621a4d8820fcd2c0ad
- views/david/3/4184ab71db6849621a4d8820fcd2c0ad
- views/david/3/4184ab71db6849621a4d8820fcd2c0ad
```

If rendering many templates the output is inscrutable, and it's impossible
to see how many cache misses there were.

Revert ca6aba7f and implement a better way later.

Having collection caching that wraps templates and automatically tries
to infer if they are cachable proved to be too much of a hassle.

We'd rather have it be something you explicitly turn on.

This removes much of the code and docs to explain the previous automatic
behavior.

This change also removes scoped cache keys and passing cache_options.

fix typo

Fixes #23645

When you're using an `attr_accessor` for a record instead of an
attribute in the database there's no way for the record to know if it
has `changed?` unless you tell it `attribute_will_change!("attribute")`.

The change made in 27aa4dda updated validations to check if a record was
`changed?` or `marked_for_destruction?` or not `persisted?`. It did not
take into account virtual attributes that do not affect the model's
dirty status.

The only way to fix this is to always validate the record if the
attribute does not belong to the set of attributes the record expects
(in `record.attributes`) because virtual attributes will not be in that
hash.

I think we should consider deprecating this particular behavior in the
future and requiring that the user mark the record dirty by noting that
the virtual attribute will change. Unfortunately this isn't easy because
we have no way of knowing that you did the "right thing" in your
application by marking it dirty and will get the deprecation warning
even if you are doing the correct thing.

For now this restores expected behavior when using a virtual attribute
by always validating the record, as well as adds tests for this case.

I was going to add the `!record.attributes.include?(attribute)` to the
`should_validate?` method but `uniqueness` cannot validate a virtual
attribute with nothing to hold on to the attribute. Because of this
`should_validate?` was about to become a very messy method so I decided
to split them up so we can handle it specifically for each case.