Fixes #25653.

Where appropriatei, prefer the more concise Regexp#match?,
String#include?, String#start_with?, or String#end_with?

Changing the order of method chaining `merge` and other query
method such as `joins` should produce the same result.

```ruby
class Topic < ApplicationRecord
  scope :safe_chaininig,   -> { joins(:comments).merge(Comment.newest) }
  scope :unsafe_chaininig, -> { merge(Comment.newest).joins(:comments) } #=> NoMethodError
end
```

[ci skip]

Unlike `one?` and `none?`, `empty?` has interactions with methods
outside of enumerable. It also doesn't fit in the same vein.
`Topic.any?` makes sense. `Topic.empty?` does not, as `Topic` is not a
container.

Fixes #24808
Close #24812

This reverts commit f6db31ec.

Reason:
Scope names can very easily conflict, particularly when sharing Concerns
within the team, or using multiple gems that extend AR models.

It is true that Ruby has the ability to detect this with the -w option, but the
reality is that we are depending on too many gems that do not care about Ruby
warnings, therefore it might not be a realistic solution to turn this switch on
in our real-world apps.

Given a default_scope on a parent of the current class, where that
parent is not the base class, the parent's STI condition would become
attached to the evaluated default scope, and then override the child's
own STI condition.

Instead, we can treat the STI condition as though it is a default scope,
and skip it in this situation: the scope will be merged into the base
relation, which already contains the correct STI condition.

Fixes #22426.

While the commit message (and changelog example) in
5e0b555b talked about sibling classes,
the added test had a child ignore its parent's scoping, which seems less
reasonable.

Fixes #19528

fix for mysql2 test

better test

Code such as the following will be corrected.

    Developer.where(id: -Float::INFINITY...2).unscope(where: :id)

The testing of error messages have been implemented wrongly a few times.
This is an attempt to fix it.

For example, some of these test should have failed with the new code.
The reason they are not failling with the new string is the fact they
were not being tested beforehand.

It looks like the only reason `current_scope` was thread local on
`base_class` instead of `self` is to ensure that when we call a named
scope created with a proc on the parent class, it correctly uses the
default scope of the subclass. The reason this wasn't happening was
because the proc captured `self` as the parent class, and we're not
actually defining a real method. Using `instance_exec` fixes the
problem.

Fixes #18806

The only place it was accessed was in tests. Many of them have another
way that they can test their behavior, that doesn't involve reaching
into internals as far as they did. `AssociationScopeTest` is testing a
situation where the where clause would have one bind param per
predicate, so it can just ignore the predicates entirely. The where
chain test was primarly duplicating the logic tested on `WhereClause`
directly, so I instead just make sure it calls the appropriate method
which is fully tested in isolation.

This is no longer required now that we are injecting a type caster
object into the Arel table, with the exception of uniqueness
validations. Since it calls `ConnectionAdapter#type_cast`, the value has
already been cast for the database. We don't want Arel to attempt to
cast it further, so we need to continue wrapping it in a quoted node.
This can potentially go away when this validator is refactored to make
better use of `where` or the predicate builder.

Part of the larger refactoring to remove type casting from Arel. We can
inform it that we already have the right type by wrapping the value in
an `Arel::Nodes::Quoted`. This commit can be reverted when we have
removed type casting from Arel in Rail 5.1

This commit fixes the following case.

    User.where(User.arel_table[:created_at].lteq(1.year.ago)).unscope(where :created_at)

`Computer` class needs to be require

See #17217 for more details

This changes the actual exception `NoMethodError: undefined method `call'
for #<ActiveRecord::Relation []>` to a `ArgumentError` when try to define
a scope without a callable.

follow up for #17052

For now, we don't want to take "scoping" calls in to account when
calculating cache keys for relations, so just opt-out.

Eagerly loaded collection and singular associations are ignored by the StatementCache, which causes errors when the queries they generate reference columns that were not eagerly loaded.

This commit skips the creation of the StatementCache as a fix for these scenarios.

Added a few more methods on Module/Class to the dangerous class methods
blacklist. (Technically, allocate and new are already protected currently because
we happen to redefine them in the current implantation.)

Closes #16792

This reverts commit 9a1abedc, reversing
changes made to c72d6c91.

Conflicts:
	activerecord/CHANGELOG.md
	activerecord/test/models/comment.rb

This change break integration with activerecord-deprecated_finders so
I'm reverting until we find a way to make it work with this gem.

Changed the call to a scope block to be evaluated with instance_eval.
The result is that ScopeRegistry can use the actual class instead of base_class when
caching scopes so queries made by classes with a common ancestor won't leak scopes.

Add tests to make sure scopes cannot be create with names such as:
private, protected, public.
Make sure enum values don't collide with those methods too.

arel methods are not supposed to be public API for ActiveRecord

See #13875