References dfb5a82b.

Update `supports_rename_index?` version for MariaDB

Looks like the CI failure is caused by rename index on a foreign key
constraint.

https://buildkite.com/rails/rails/builds/69099#1b008fd1-1d2f-4c87-934a-8cdfd6e42c67/1022-2096

Improve performance for loaded association's `first`

Fix left joins order when merging multiple left joins from different associations

Fix `pluck` to correctly type cast same column names and association columns

Casting aggregated value takes attribute type precedence over database type

Remove Indexer class from Rails Guide generator

Follow up to #39255, #39039.

One of the purpose of this was to unify the behavior between the
databases.

Original code was:

```ruby
    type   = result.column_types.fetch(column_alias) do
      type_for(column_name)
    end
```

The code will attempt looking up type from `column_types`, then fallback
to attribute types, so I supposed the code was originally intended to
cast a value by the database types.

But now, most modern clients will already return casted values, and no
longer use `column_types`, except Postgres.
As a result, now most adapter accidentally fallback to attribute types.
Since casted by attribute types sometimes doesn't return numeric values,
I've unified the behavior to use database types consistently in #39039.

But later, I've learned that attribute types have important settings
like time zone aware attributes (#39255), and some existing code relying
on attribute types over database types (#39271).

I've changed all aggregated values are casted by attribute types.

Fixes #39271.

This commit removes the orphaned Indexer class from the Rails Guide
generator. The indexer was removed in 2012 during the move from Textile
to Markdown in commit 5e2866cc.

I can't for the life of me reproduce the failures occurring on buildkite
but I beleive this is the fix. We need to only run this on sqlite3
because we are using a sqlite3 database.

Delegate to scope values (e.g. `offset_value`, `order_values`) is slow.

We can avoid that if records are already loaded.

```ruby
class Post < ActiveRecord::Base
  has_many :comments
end

class Comment < ActiveRecord::Base
  belongs_to :post
  has_many :likes
end

class Like < ActiveRecord::Base
  belongs_to :post
end

10.times { Post.create! }
30.times { |i| Comment.create!(post_id: 1 + i % 10) }
150.times { |i |Like.create!(comment_id: 1 + i % 30) }

post = Post.includes(comments: :likes).last

result = Benchmark.measure do
  100.times { post.comments.each { |c| c.likes.first.id } }
end

puts
puts result
```

Before:

```
  0.013542   0.000582   0.014124 (  0.014125)
```

After:

```
  0.000938   0.000017   0.000955 (  0.000952)
```

Fixes #38252.

This moves the previous test into the old test and reuses the connection
that that test establishes rather than requiring we muck with temporary
connection pool.

The change here is more correct than the previous code since we're
establishing new connections we should be checking the newly established
reading and writing connections are the same, not checking against the
existing ActiveRecord::Base.connection.

The test here also most closely emulates a real application using
multiple databases.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

#38597 is caused by #35864.

To reproduce this issue, at least it is required four different models
and three left joins from different relations.

When merging a relation from different model, new stashed (left) joins
should be placed before existing stashed joins, but #35864 had broken
that expectation if left joins are stashed multiple times.

This fixes that stashed left joins order as expected.

Fixes #38597.

That issues are caused by using only the model's cast types on the
relation.
To fix that issues, use the attribute's type caster takes precedence
over the model's cast types on the relation.

Fixes #35232.
Fixes #36042.
Fixes #37484.

Association look up requires association class is loaded especially for
through association. Just apply that look up only in aggregation column
for now.

Fix type casting aggregated values on association's attributes

Follow up of #39255.

Previously aggregation functions only use the model's attribute types on
the relation for type cast, this will be looking up association's
attribute and type caster if a column name is table name qualified.

Fixes #39248.

Add did you mean ssupport to UrlGeneration errors

Revert "Remove deprecated `ActionMailer::DeliveryJob` and `ActionMailer::Parameterized::DeliveryJob`

Followup to b3102205.

Test failing on Windows because binary file being read inconsistently

We sometimes hook in to the DYM gem to provide better error messages for
routes.  This commit changes the assertions so that if DYM decides to
add something helpful, we don't fail the build

Revert "Remove deprecated `ActionMailer::DeliveryJob` and `ActionMailer::Parameterized::DeliveryJob`"

This reverts commit 0f9249c9.

Reverted because this wasn't warning in custom jobs and therefore
applications may have not seen the deprecation. We'll need to fix the
deprecation to warn for custom jobs so that applications can migrate.

Avoid confliting Kernel-named scopes on Relation

Fix `minimum` and `maximum` on time zone aware attributes

A previous change made singleton methods eagerly define their relation
methods if it shared a name with a method on Kernel. This caused issues
with a few methods which were both defined on Kernel and on
AcitveRecord::Relation.

This commit avoids defining the method if it exists on AR::Relation.

Remove implementation of unchecked_serialize

Since we're checking `serializable?` in the new `HomogeneousIn`
`serialize` will no longer raise an exception. We implemented
`unchecked_serialize` to avoid raising in these cases, but with some of
our refactoring we no longer need it.

I discovered this while trying to fix a query in our application that
was not properly serializing binary columns. I discovered that in at
least 2 of our active model types we were not calling the correct
serialization. Since `serialize` wasn't aliased to `unchecked_serialize`
in `ActiveModel::Type::Binary` and `ActiveModel::Type::Boolean` (I
didn't check others but pretty sure all the AM Types are broken) the SQL
was being treated as a `String` and not the correct type.

This caused Rails to incorrectly query by string values. This is
problematic for columns storing binary data like our emoji columns at
GitHub. The test added here is an example of how the Binary type was
broken previously. The SQL should be using the hex values, not the
string value of "🥦" or other emoji.

We still have the problem `unchecked_serialize` was supposed to fix -
that `serialize` shouldn't validate data, just convert it. We'll be
fixing that in a followup PR so for now we should use `serialize` so we
know all the values are going through the right serialization for their
SQL.

This is the opposite direction of #39039.

#39111 fixes `minimum` and `maximum` on date columns with type casting
by column type on the database. But column type has no information for
time zone aware attributes, it means that attribute type should always
be precedence over column type. I've realized that fact in the related
issue report #39248.

I've reverted the expectation of #39039, to make time zone aware
attributes works.

Optimize dangerous_attribute_method?

Depends on newer Rack API.

This reverts commit fbf1d82e.