While working on some more indepth changes to Rails internal connection
management we noticed that it's confusing in some cases that the `role`
is implcit when using a `shard`. For example, if you passed a `shard`
and not a `role` in an un-nested block the default `role` would be
`writing`.

```
ActiveRecord::Base.connected_to(shard: :one) do
  # connected to writing
end
```

However in cases where nesting is used it could be confusing to
application authors that the role is inherited:

```
ActiveRecord::Base.connected_to(role: :reading) do
  ActiveRecord::Base.connected_to(shard: :one) do
    # will read from shard one replica, not write to primary
  end
end
```

Since this could be potentially confusing, and extremely hard to track
in complex applications, the best approach is to require `role` when
using `shard` which is what this PR does.

Note: the code for this method is...getting unweildy. Once the
`database` argument is fully deprecated we can remove most of the guards
and make `role` required by removing `nil` from the keyword argument.
Until then we need to support required arguments in this round about way.

https://github.com/rails/rails/commit/895134bcff294b05d6f6ebb101f60e3083ec5461#diff-7789e18ec0a61c6845755a257e6eb34fR3
https://github.com/rails/rails/commit/ee9e308f686ac1c7b0714671a1dcf1d96de87d70#diff-5e9551294914b338d923032fa904c6beR103
https://github.com/rails/rails/commit/5f63c771f7ce751fefd000470bf4ccab421988d7#diff-600d5368b55e46ed961abb4295977ac3R506
https://github.com/rails/rails/commit/48b6bacbc534d4be3fa89bc19ea83c357a20e598#diff-279ac5c088a3ee7e9f954bbc10d1b773R246
https://github.com/rails/rails/commit/49adb7f4c61de8cbb02c4a207dbd56093d99e795#diff-0cbe7171fdd7821fd5836896849141c0R111
https://github.com/rails/rails/commit/9bfe89e68ee61d9c8ed71ac98c783a7e47bdb608#diff-9c1c95b001e3680ba8a473cf23508b68R8
https://github.com/rails/rails/commit/a0f18e60900fc45eb3524ab3cdfe57be430d6016#diff-bef0ae2c16dacf77bfd2ba099af8a330R47
https://github.com/rails/rails/commit/8b4d344815655027d9f7584c0a59271dce8f1d5a#diff-09660f59aee7ec893ad609315e8843c5R18
https://github.com/rails/rails/commit/49d1b5a98dc50ca59bbfb817f90eb5c2c2645d30#diff-531e71a9d5fdc8181f38ce4416553694R107
https://github.com/rails/rails/commit/b674f04756e2e23fc18308319e4de8ff562575f4#diff-7521c0bb452244663b689e77658e63e3R98
https://github.com/rails/rails/commit/a9012af6883284a35bc5e6166507d429fe10482d#diff-60bdcf1e1954ec56d41fc4c7bd8d3e39R512
https://github.com/rails/rails/commit/6380aee182a6acb4f5062c5aa377d290e696e4b7#diff-5158c234d5e19bb1cffadcbc088400f1R262
https://github.com/rails/rails/commit/c7820d8124c854760a4d288334f185de2fb99446#diff-f4614e7ba8081c0c9e20fe64b6374228R60
https://github.com/rails/rails/commit/8df7ed3b88fc9f19446d7207a745a331893b81cd#diff-0495ed68f82d1bbde593ab5491eab24aR169
https://github.com/rails/rails/commit/6f94260ac67755fbc4d89e7dd9ba6be04abfa9e7#diff-7ecb6672f3fd37dfb79c4539395d3857R28
https://github.com/rails/rails/commit/03e44f93001db97953917e0a100c627e189e2be6#diff-e9234c4c6668852448059c0a35840bcaR185

`connectes_to` should only be called on `ActiveRecord::Base` or abstract
classes. This is recommended in the documentation but until now was not
enforced by the code. It's unsafe to open too many connections to mysql
(and probably other databases), so it's safest to have 1 class for the
connection and subclass from that.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

This reverts commit 55d9e494, reversing
changes made to 03e987cd.

Legacy mysql adapter is already removed in #22642.

Revert "Revert "Raise ConnectionNotEstablished rather than StatementInvalid in Mysql2Adapter#quote_string""

This reverts commit 6f92c40d.

It is a common use case especially for MySQL users.

This reverts commit b8ab1f89, reversing
changes made to 73ae5655.

If you're using the `nulls_first` or `nulls_last` functionality with an explicit ordering, then previously it wasn't properly handling calls to `#reverse` (called through `reverse_order`). This commit changes the behavior to match what would be expected.

Active Record already supports adding `NOT VALID` foreign key constraints in PostgreSQL, but back in #31323 when check constraint support was initially added, the ability to add a check constraint and validate it separately was not included. This adds that functionality!

Closes #40187.

This prevents the `from` query method from being ignored silently in the
resulting SQL query that is generated.

The current behaviour of reverse_order, when presented with an
existing order that is an Arel expression, is to ignore it.
This isn't quite in keeping with how it handles Arel attributes
(which it reverse) or arbitrary strings (which throw an exception).

The easy path would be to throw an exception, but we don't have to.
Any SQL expression that is a valid default sort expression can be
reversed with DESC.

It follows that if there's an existing Arel::Nodes::NodeExpression
that is not already wrapped with an Arel::Nodes::Ordering, then
it can be reversed with DESC.

This reverts commit 55d9e494, reversing
changes made to 03e987cd.

Legacy mysql adapter is already removed in #22642.

Originally, time object is decorated after `changes_applied` by
`forgetting_assignment` (`value_for_database`).

https://github.com/rails/rails/blob/d2cdf0be675b44771f950697fc0b19ef0ea453f9/activemodel/lib/active_model/attribute.rb#L67-L69
https://github.com/rails/rails/blob/d2cdf0be675b44771f950697fc0b19ef0ea453f9/activemodel/lib/active_model/attribute.rb#L55-L57

Before #36352, fortunately `apply_seconds_precision` will return
undecorated new time object by everytime `value.change` is called.

Now, we need to explicitly check a time value is decorated or not in
`cast_value`.

Fixes #36910.

If a table is joined multiple times, those tables are aliased other than
the first one.

It happens easily on self referential associations, and in that case
currently there is no way to work custom attribute (type casting) and
attribute alias resolution for aliased tables in `where` conditions.

To address the issue, it will allow `where` references association names
as table aliases. If association names are referenced in `where`, those
names are used for joined table alias names.

```ruby
class Comment < ActiveRecord::Base
  enum label: [:default, :child]
  has_many :children, class_name: "Comment", foreign_key: :parent_id
end

# ... FROM comments LEFT OUTER JOIN comments children ON ... WHERE children.label = 1
Comment.includes(:children).where("children.label": "child")
```

Fixes #39727.

In 7f938cac the test model `Man` was renamed to `Human`. Maybe this is a
good time to also change `horrible_human` and `dirty_human` to
`happy_human` and `confused_human`.

While this change is mostly cosmetic change, the phrase "dirty man" has
a negative meaning.

The adjectives "confused" and "puzzled" were chosen because they are
used for defining associations with errors.

Not disconnecting the connections in the pool results in a session left idling in the DB.

An idle session will prevent the database being dropped and affect
commands like `bin/rails db:test:prepare`. While this is an edge case,
it is still good practice to clean up the connections in the pool.

If an inverse association isn't found we can suggest similar associations:

```
class Human < ActiveRecord::Base
  has_one :dirty_face, class_name: "Face", inverse_of: :dirty_human
end

class Face < ActiveRecord::Base
  belongs_to :human, inverse_of: :face
  belongs_to :horrible_human, class_name: "Human", inverse_of: :horrible_face
end
Human.first.dirty_face

Could not find the inverse association for dirty_face (:dirty_human in Face)
Did you mean?  human
               horrible_human
              ....
```
Co-authored-by: NDaniel Colson <danieljamescolson@gmail.com>

Before 29874cc4 the order values
would be deduplicated when the SQL query is generated, but now
it has to be eager.

This is an alternative of #29722.

Before Rails 6.1, storing demodulized class name is supported only for
STI type by `store_full_sti_class` class attribute.

Now `store_full_class_name` class attribute can handle both STI and
polymorphic types.

Closes #29722.

See also #29601, #32048, #32148.

Related to #35210.

We sometimes use `select` to limit unused columns for performance.

For example, `GET /posts/1` (post detail) usually use (almost) all
columns, but `GET /posts` (post list) does not always use all columns
(e.g. use `id` and `title` for the list view, but `body` is not used).

If an association is eager loaded, the limited `select` doesn't works as
expected, eager loading will load all columns on the model, plus also
load the `select` columns additionally. It works differently with
natural load and preload. It means that changing natural load or preload
to eager load (or vice versa) is unsafe.

This fixes eager loading that always load all columns (plus extra
`select` columns), to respect the `select` columns like as others.

```ruby
post = Post.select("UPPER(title) AS title").first
post.title # => "WELCOME TO THE WEBLOG"
post.body  # => ActiveModel::MissingAttributeError

# Rails 6.0 (ignore the `select` values)
post = Post.select("UPPER(title) AS title").eager_load(:comments).first
post.title # => "Welcome to the weblog"
post.body  # => "Such a lovely day"

# Rails 6.1 (respect the `select` values)
post = Post.select("UPPER(title) AS title").eager_load(:comments).first
post.title # => "WELCOME TO THE WEBLOG"
post.body  # => ActiveModel::MissingAttributeError
```

Someone had relied on the behavior that preloading with a given scope,
but the behavior has lost in #35496 to fix the minor bug that unloading
through association.

Basically we don't guarantee the internal behavior, but the bugfix can
be achieved without any breaking change, so I've restored the lost
functionality.

Fixes #36638.
Fixes #37720.

If we enter a `connected_to` block and call `establish_connection` like
the test added here we need to ensure that `shard: current_shard` is passed
to the handler, otherwise the connection will be established on
`default` not on `shard_one`.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

After renaming `Man` to `Human` the variable letter `m` in these tests
ends up being pretty confusing. Rather than rename it to `h`, this
commit replaces it with the full word `human`.

Since I was already renaming things, I also went ahead and replaced `f`
with `face`, `i` with `interest`, and `a` with `author`.

The commit replaces the `Man` model used in tests with a `Human` model. It
also replaces the existing `Human` model with a `SuperHuman` model
inheriting from `Human`.

While this may seem like a cosmetic change, I see it as more of an
inclusivity change. I think it makes sense for a number of reasons:

* Prior to this commit the `Human` model inherited from `Man`. At best
  this makes no sense (it should be the other way around). At worst it
  is offensive and harmful to the community.
* It doesn't seem inclusive to me to have exclusively male-gendered
  examples in the codebase.
* There is no particular reason for these examples to be gendered.
* `man` is hard to grep for, since it also matches `many, manager,
  manual, etc`

For the most part this is a simple search and replace. The one exception
to that is that I had to add the table name to the model so we could use
"humans" instead of "humen".

Follow up of #40000.

In #40000, `eager_load(:general_categorizations, :general_posts)` works,
but `eager_load(:general_posts, :general_categorizations)` doesn't work
yet.

This implements the deduplication for the case of reversed eager loading
order.

In `connected_to` one of the deprecated arguments wasn't well tested so
the incorrect methods signature wasn't caught by the tests.

This change updates the caller when `connected_to` uses the database
key.

I've also cleaned up a few arguments that weren't necessary. Since
the handler methods set defaults for the `shard` key, we don't need to
pass that in `establish_connection` when not using the sharding API.

This change makes a helper method for resetting connection handlers in
the Active Record tests. The change here is relatively small and may
seem unnecessary. The reason we're pushing this change is for upcoming
refactoring to connection management. This change will mean that we can
update one location instead of 9+ files to reset connections. It will
reduce the diff of our refactoring and make reusing this code easier in
the future.

The method name chosen is purposefully `clean_up_connection_handler`
over `clean_up_connection_handlers` because in the future there will
only be one handler.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

This change ensures that the connection methods are using kwargs instead
of positional arguments. This change may look unnecessary but we're
working on refactoring connection management to make it more robust and
flexible so the method signatures of the methods changed here will
continue to evolve and change.

This commit does not change any released public APIs. The `shard` and
`owner_name` arguments were added in 6.1 which is not released yet.
Using kwargs will allow these methods to be more flexible and not get
super ugly as we change their underlying behavior. The kwargs let us
support multiple non-positional arguments with default.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

While debugging a different problem I'm working on I realized that this
method `with_temporary_connection_pool` isn't necessary in most of the
cases we're using it for.

Anywhere we establish new connections inside the block won't throw away
those new connections. I also removed this from places that can use the
existing connection and don't need a new temporary pool. I'm not sure if
this file was using it in many places because of copy / paste or real
issues that are no longer present.