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

```ruby
class Post < ActiveRecord::Base
  alias_attribute :alias_id, :id
end

Benchmark.ips do |x|
  x.report("find_by alias") do
    Post.find_by(alias_id: 1)
  end
end
```

Before:

```
Warming up --------------------------------------
       find_by alias   419.000  i/100ms
Calculating -------------------------------------
       find_by alias      4.260k (± 3.9%) i/s -     21.369k in   5.023768s
```

After:

```
Warming up --------------------------------------
       find_by alias     1.182k i/100ms
Calculating -------------------------------------
       find_by alias     12.122k (± 4.1%) i/s -     61.464k in   5.080451s
```

Related to 7d4cc56e.

`assert_no_queries` sometimes fails due to counting implict schema info
load queries, most case that is enough to just ignore it.

https://buildkite.com/rails/rails/builds/69598#321bb1bc-ec67-40cd-813f-68dc7809ddde/1444-1452

Like as before Rails 6.0.

Closes #38309.

Follow up of #37434.

The results is deduplicated when eager loading. However, eager loading
for no :has_many with limit and joins for :has_many do not deal with
this while eager loading for :has_many deals with this.

Fixes #37356

The error happens in PostgreSQL when using `relation.exists?` with
`distinct`, `offset` and `order` for joined table.
However, the error does not happen if either `distinct` or `offset` is
removed. This behavior is confusing.

Fixes #36632

It is for agnostic test case, since quoted table name may include `.`
for all adapters, and `[` / `]` for sqlserver adapter.

Before 1340498d, `order` with no-op value (e.g. `nil`, `""`) had broken
the contract of ordinal methods, which returns a result deterministic
ordered.

An `author` has a lots of `posts` in the fixtures, so the result of
`author.post` and finding a `post` by `author_id` is non-deterministic.

https://travis-ci.org/rails/rails/jobs/504332292#L1202-L1208

Use "support/stubs/strong_parameters" instead.

The `distinct` affects (reduces) rows of the result, so it is important
part when both `distinct` and `offset` are given.

Replacing SELECT clause to `1 AS one` and removing `distinct` and
`order` is just optimization for the `exists?`, we should not apply the
optimization for that case.

Fixes #35191.

Currently several queries cannot return correct result due to incorrect
`RangeError` handling.

First example:

```ruby
assert_equal true, Topic.where(id: [1, 9223372036854775808]).exists?
assert_equal true, Topic.where.not(id: 9223372036854775808).exists?
```

The first example is obviously to be true, but currently it returns
false.

Second example:

```ruby
assert_equal topics(:first), Topic.where(id: 1..9223372036854775808).find(1)
```

The second example also should return the object, but currently it
raises `RecordNotFound`.

It can be seen from the examples, the queries including large number
assuming empty result is not always correct.

Therefore, This change handles `RangeError` to generate executable SQL
instead of raising `RangeError` to users to always return correct
result. By this change, it is no longer raised `RangeError` to users.

Clarify changelog entry
Related to #34891

Allow `ActionController::Params` as argument of
`ActiveRecord::Base#exists?`

https://bugs.ruby-lang.org/issues/14133

When calling ordered finder methods such as +first+ or +last+ without an
explicit order clause, ActiveRecord sorts records by primary key. This
can result in unpredictable and surprising behaviour when the primary
key is not an auto-incrementing integer, for example when it's a UUID.
This change makes it possible to override the column used for implicit
ordering such that +first+ and +last+ will return more predictable
results. For Example:

  class Project < ActiveRecord::Base
    self.implicit_order_column = "created_at"
  end

Any type can be a primary key, so blank string is also valid value.

Closes #26356.

At https://github.com/rails/rails/commit/fc0e3354af7e7878bdd905a95ce4c1491113af9a,

```rb
relation = relation.where(conditions)
```

was rewritten to:

```rb
relation.where!(condition)
```

This change accidentally changed the result of `Topic.exists?({})` from true to false.

To fix this regression, first I moved the blank check logic (`opts.blank?`) from `#where` to `#where!`,
because I thought `#where!` should be identical to `#where`, except that instead of returning a new relation,
it adds the condition to the existing relation.

But on second thought after some discussion on https://github.com/rails/rails/pull/34329,
I started to think that just fixing `#construct_relation_for_exists` is more preferable
than changing `#where` and `#where!`.

When you pass an empty array to find we know we shoudl return an empty
array but it is surprising that we are returning the original empty
array instead of a new one.

This reverts commit d162188d, reversing
changes made to 35767828.

Reason: #24131 conflicts the #5153's default order contract, it means
that existing apps would be broken by that change.

We don't want to break existing apps without a deprecation cycle.

https://travis-ci.org/rails/rails/jobs/375326992#L1160-L1166

This autocorrects the violations after adding a custom cop in
3305c78dcd.

Prevent `ActiveRecord::FinderMethods#limited_ids_for` from using correct primary
key values even if `ORDER BY` columns include other table's primary key.

Fixes #28364.

* Add test case for open-ended range.
* Add test case for numeric range for string column.

Follow up of #31724.

If `composed_of` objects have multiple mappings, array predicate handler
can not correctly handle the expanded condition.

We need to handle it like polymorphic association objects.

Fix not expanded problem when passing an Array object as argument to the where method using composed_of column.

Fixes #31723

```
david_balance = customers(:david).balance
Customer.where(balance: [david_balance]).to_sql

# Before: WHERE `customers`.`balance` = NULL
# After : WHERE `customers`.`balance` = 50
```

`relation.exists?` just wants to know if there is a result or not, does
not need the exact records matched. Therefore, an intermediate SELECT
query for eager loading is not necessary.