Make AR::Middleware::DatabaseSelector loadable without full core ext

More Enumerable `first` and `last` for `ActiveRecord::Result`

Remove invalid autoloads

`Result#first` was added at #25507. As I said at https://github.com/rails/rails/pull/25507#issuecomment-228446339,
I still prefer less code, `Result#first` is used only in `select_one`,
and `select_one` is not used in the codebase, i.e. `Result#first` and
`Result#last` are not used in the codebase. I'd not prefer to have
dedicated code for such like rarely used (almost unused) feature.

Instead of having limited `Result#first` (doesn't allow number), I'd
prefer to just use `Enumerable#first`.

Case insensitive mutation tracking

Support `relation.and` for intersection as Set theory

It is cheaper than mutating casted value directly.

See https://github.com/rails/rails/pull/38867#issuecomment-639238234 for
more details.

As described at #39328, `relation.merge` behaves inspired as Hash-like
merge for where clause. In other words, currently there is no official
way to intersect the result by both relation conditions (i.e. there is
no official way to maintain both relation conditions).

To resolve that issue, I'd like to support a way to intersect relations
as `relation.and`.

```ruby
david_and_mary = Author.where(id: [david, mary])
mary_and_bob   = Author.where(id: [mary, bob]) # => [bob]

david_and_mary.merge(mary_and_bob) # => [mary, bob]

david_and_mary.and(mary_and_bob) # => [mary]
david_and_mary.or(mary_and_bob)  # => [david, mary, bob]
```

Fixes #39232.

Extra predicate handler for just one line preprocess is too expensive.

```ruby
ActiveRecord::Schema.define do
  create_table :users, force: true do |t|
  end
end

class User < ActiveRecord::Base
end

predicate_builder = User.predicate_builder

attr = User.arel_attribute(:id)
user = User.create!
user_id = user.id

Benchmark.ips do |x|
  x.report("build:user") { predicate_builder.build(attr, user) }
  x.report("build:user_id") { predicate_builder.build(attr, user_id) }
end
```

Before:

```
Warming up --------------------------------------
          build:user    11.626k i/100ms
       build:user_id    23.314k i/100ms
Calculating -------------------------------------
          build:user    114.151k (± 2.0%) i/s -    581.300k in   5.094468s
       build:user_id    226.420k (± 2.3%) i/s -      1.142M in   5.048205s
```

After:

```
Warming up --------------------------------------
          build:user    21.484k i/100ms
       build:user_id    24.307k i/100ms
Calculating -------------------------------------
          build:user    210.207k (± 1.8%) i/s -      1.053M in   5.009623s
       build:user_id    238.276k (± 2.1%) i/s -      1.215M in   5.102951s
```

Deprecate inconsistent behavior that merging conditions on the same column

Related to #39250 and #39236.

The purpose of the change here is to unify inconsistent behavior on the
merging.

For now, mergee side condition is replaced by merger side condition only
if both arel nodes are Equality or In clauses.

In other words, if mergee side condition is not Equality or In clauses
(e.g. `between`, `or`, `gt`, `lt`, etc), those conditions will be kept
even on the same column.

This behavior is harder to predict unless people are familiar with the
merging behavior.

Originally I suppose this behavior is just an implementation issue
rather than an intended one, since `unscope` and `rewhere`, which were
introduced later than `merge`, works more consistently.

Since most of the conditions are usually Equality and In clauses, I
don't suppose most people have encountered this merging issue, but I'd
like to deprecate the inconsistent behavior and will completely unify
that to improve a future UX.

```ruby
# Rails 6.1 (IN clause is replaced by merger side equality condition)
Author.where(id: [david.id, mary.id]).merge(Author.where(id: bob)) # => [bob]

# Rails 6.1 (both conflict conditions exists, deprecated)
Author.where(id: david.id..mary.id).merge(Author.where(id: bob)) # => []

# Rails 6.1 with rewhere to migrate to Rails 6.2's behavior
Author.where(id: david.id..mary.id).merge(Author.where(id: bob), rewhere: true) # => [bob]

# Rails 6.2 (same behavior with IN clause, mergee side condition is consistently replaced)
Author.where(id: [david.id, mary.id]).merge(Author.where(id: bob)) # => [bob]
Author.where(id: david.id..mary.id).merge(Author.where(id: bob)) # => [bob]
```

Convert route params array into object

This PR converts the route params array into an object and moves the
error generation code into its own object as well. This is a refactoring
of internal code to make it easier to change and simplier for internals
to interface with. We have two new objects:

1) `RouteWithParams`

Previously `#generate` returned an array of parameterized parts for a
route. We have now turned this into an object with a `path` and a
`params methods` to be able to access the parts we need.

2) `MissingRoute`

`#generate` was also responsible for constructing the message for the
error. We've moved this code into the new `MissingRoute` object so it
does that work instead.

This change makes these methods reusable throughout the code and easier
for future refactoring we plan to do.
Co-authored-by: NAaron Patterson <aaron.patterson@gmail.com>

Silence Rake task backtraces

Silence Rake task backtraces, similar to Rails::BacktraceCleaner.
Application lines are preserved, but all other lines are hidden.

This also affects unrecognized tasks, causing the backtrace to be hidden
entirely.  Closes #39524.
Co-authored-by: NPetrik <petrik@deheus.net>

Follow up to #39409.

It is too pessimistic, we can check the attribute whether aggregated or
not by `reflect_on_aggregation`.

```ruby
ActiveRecord::Schema.define do
  create_table :posts, force: true do |t|
  end

  create_table :comments, force: true do |t|
    t.belongs_to :post
  end
end

class Post < ActiveRecord::Base
  has_many :comments
end

class Comment < ActiveRecord::Base
  belongs_to :post
end

post = Post.create!

Benchmark.ips do |x|
  x.report("find_by post") { Comment.find_by(post: post) }
end
```

Before:

```
Warming up --------------------------------------
        find_by post   395.000  i/100ms
Calculating -------------------------------------
        find_by post      4.026k (± 3.1%) i/s -     20.145k in   5.008059s
```

After:

```
Warming up --------------------------------------
        find_by post     1.183k i/100ms
Calculating -------------------------------------
        find_by post     11.859k (± 2.5%) i/s -     60.333k in   5.090685s
```

This reverts commit c1b8833e.

Revert "Lock benchmark-ips version < 2.8"

This reverts commit 62bfa50f.

LoadError is fixed in benchmark-ips 2.8.2.

https://github.com/evanphx/benchmark-ips/pull/101

Delegating to just one line method is to not be worth it.
Avoiding the delegation makes `read_attribute` about 15% faster.

```ruby
ActiveRecord::Schema.define do
  create_table :users, force: true do |t|
    t.string :name
  end
end

class User < ActiveRecord::Base
  def fast_read_attribute(attr_name, &block)
    name = attr_name.to_s
    name = self.class.attribute_aliases[name] || name

    name = @primary_key if name == "id" && @primary_key
    @attributes.fetch_value(name, &block)
  end
end

user = User.create!(name: "user name")

Benchmark.ips do |x|
  x.report("read_attribute('id')") { user.read_attribute('id') }
  x.report("read_attribute('name')") { user.read_attribute('name') }
  x.report("fast_read_attribute('id')") { user.fast_read_attribute('id') }
  x.report("fast_read_attribute('name')") { user.fast_read_attribute('name') }
end
```

```
Warming up --------------------------------------
read_attribute('id')   165.744k i/100ms
read_attribute('name')
                       162.229k i/100ms
fast_read_attribute('id')
                       192.543k i/100ms
fast_read_attribute('name')
                       191.209k i/100ms
Calculating -------------------------------------
read_attribute('id')      1.648M (± 1.7%) i/s -      8.287M in   5.030170s
read_attribute('name')
                          1.636M (± 3.9%) i/s -      8.274M in   5.065356s
fast_read_attribute('id')
                          1.918M (± 1.8%) i/s -      9.627M in   5.021271s
fast_read_attribute('name')
                          1.928M (± 0.9%) i/s -      9.752M in   5.058820s
```

Expand on specs for foreign keys with to_table and add make doc changes

Remove assumption that a primary config exists

Fix schema cache load and corresponding test

Expand on specs of self join and add make doc changes to suggest users to also do  foreign_key when doing self join

This test was incorrect. `primary` was winning for the schema cache load
but when you boot an application it's actually the first configuration
that wins (in a multi db app).

The test didn't catch this because I forgot to add a migrations_paths to
the configuration.

We updated the schema cache loader railtie as well because any
application that didn't have a `primary` config would not be able to use
the schema cache. Originally we thought we'd enforce a `primary`
configuration but no longer feel that's correct. It's simpler to say
that the first wins in a 3-tier rather than implementing a solution to
require `primary` and / or allow aliases.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>
Co-authored-by: NJohn Hawthorn <john@hawthorn.email>

Applications may not have a primary configuration so we should not
assume there is one. In both these cases we can get the right connection
without that.

For the databases.rake file we want to re-establish a connection for the
environment we're in. The first config defined under an environment for
a multi-db app will win. This is already the case on application boot so
we should be consistent.

For the info.rb file we already have a connection so we can lookup the
adapter from the connection's db_config. If a primary hadn't existed
this would have thrown an exception.

Followup to https://github.com/rails/rails/pull/39535 which removed the
assumption there was a primary config from the schema cache load
railtie.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

This reverts commit dd1aa738.

Since this ivar is updated in a synchronize block just below,
and has to be protected from other threads
Co-authored-by: NRyuta Kamizono <kamipo@gmail.com>

[ci skip]

This reverts commit 5e0ef9ca.

@num_waiting has to be synchronized with `poll` method
Co-authored-by: NRyuta Kamizono <kamipo@gmail.com>

This reverts commit ea791e53.

reason: these ivars are modified within other synchronize blocks,
        and so need to be blocked from other threads for ensuring therad safety.
Co-authored-by: NRyuta Kamizono <kamipo@gmail.com>

Link to current version of API docs [ci skip]

remove redundant require: follow #39142

It is a super edge case but the alias should be resolved before
`clear_attribute_changes` since `clear_attribute_changes` is not aware
of attribute aliases.