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

Due to inconsistent behavior when chaining scopes and one scope named after a Relation method

Validation code added in 2 places:

- scope, to prevent problematic scope names.
- enum, cause it tries to auto define scope.

https://travis-ci.org/rails/rails/jobs/263617099#L769-L775

This reverts commit 3420a145, reversing
changes made to afb66a5a.

Since b644964b `ActiveRecord::Relation` includes `Enumerable` so
delegating `collect`, `all?`, and `include?` are also unneeded.
`collect` without block returns `Enumerable` without preloading by that.
We should use `load` rather than `collect` for force loading.

assert [1, 3].includes?(2) fails with unhelpful "Asserting failed" message

assert_includes [1, 3], 2 fails with "Expected [1, 3] to include 2" which makes it easier to debug and more obvious what went wrong

Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces

Fix all violations in the repository.

The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.

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.

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.

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.

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

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.