Reliant on https://github.com/rails/rails/pull/15747 but pulled to a
separate PR to reduce noise. `has_many :through` associations have the
undocumented behavior of automatically detecting counter caches.
However, the way in which it does so is inconsistent with counter caches
everywhere else, and doesn't actually work consistently.

As with normal `has_many` associations, the user should specify the
counter cache on the `belongs_to`, if they'd like it updated.

```
activerecord/test/cases/adapters/postgresql/range_test.rb:159: warning: (...) interpreted as grouped expression
activerecord/test/cases/finder_test.rb:38: warning: shadowing outer local variable - e
activerecord/test/cases/finder_test.rb:43: warning: shadowing outer local variable - e
```

`exists?`

Pass the id of the object to the method by calling `.id` on the AR
object.

This will avoid the confusing flunk logic

When we build a query with an inline value that is a numeric (e.g.
because it's out of range for an int4) PostgreSQL doesn't use an index
on the column, since it's now comparing numerics and not int4s.

This leads to a _very_ slow query.

When we use bound parameters instead of inline values PostgreSQL
raises numeric_value_out_of_range since no automatic coercion happens.

This commit fixes two regressions introduced in cafe31a0 where
newly created finder methods #second, #third, #forth, and #fifth
caused a NoMethodError error on reload associations and where we
were pulling the wrong element out of cached associations.

Examples:

  some_book.authors.reload.second

  # Before
  # => NoMethodError: undefined method 'first' for nil:NilClass

  # After
  # => #<Author id: 2, name: "Sally Second", ...>

  some_book.first.authors.first
  some_book.first.authors.second

  # Before
  # => #<Author id: 1, name: "Freddy First", ...>
  # => #<Author id: 1, name: "Freddy First", ...>

  # After
  # => #<Author id: 1, name: "Freddy First", ...>
  # => #<Author id: 2, name: "Sally Second", ...>

Fixes #13783.

This commit bring the famous ordinal Array instance methods defined
in ActiveSupport into ActiveRecord as fully-fledged finders.

These finders ensure a default ascending order of the table's primary
key, and utilize the OFFSET SQL verb to locate the user's desired
record. If an offset is defined in the query, calling #second adds
to the offset to get the actual desired record.

Fixes #13743.

This will fix the [broken
test](https://github.com/rails/rails/commit/4a2650836680f51490e999c3c8441a2f9adff96e)
 `test_with_limiting_with_custom_select`.

The query's result was built in a hash with column name as key, if the
result have a duplicated column name the last value was
overriding the first one.

The dynamic finder was creating the method signature with the parameters name,
which may have reserved words and this way creating invalid Ruby code.

Closes: #13261

    Example:

        # Before
        Dog.find_by_alias('dog name')

        # Was creating this method
        def self.find_by_alias(alias, options = {})

        # After
        Dog.find_by_alias('dog name')

        # Will create this method
        def self.find_by_alias(_alias, options = {})

Closes #7441

We need to fix this test

This will avoid the broken window effect in our test suite

This fixes a regression. The documentation said in its introduction
paragraph that the method returns truthy/falsy, but then below it
was said that if there were no arguments you'd get `true` or `false`.
Also when the argument is exactly `false` a singleton is documented
to be returned.

The method was not returning the singletons so it didn't conform to
those special cases.

The best solution here seems to be to just return singletons in all
cases. This solution is backwards compatible. Also, the contract
has been revised because it has no sense that the predicate varies
that way depending on the input. I bet the previous contract was just
an accident, not something mixed on purpose.

Conflicts:
	activerecord/lib/active_record/relation/finder_methods.rb
	activerecord/test/cases/finder_test.rb

This method is already present in helper.rb

Some adapters require column information to do their job properly.
By enforcing the provision of the column for this internal method
we ensure that those using adapters that require column information
will always get the proper behavior.

The combination of a :uniq => true association and the #distinct call
in #construct_limited_ids_condition combine to create invalid SQL, because
we're explicitly selecting DISTINCT, and also sending #distinct on to AREL,
via the relation#distinct_value.

Rather than build a select distinct clause in #construct_limited_ids_condition,
I set #distinct! and pass just the columns into the select statement.
This requires introducing a #columns_for_distinct method to return the
select columns but not the statement itself.

When using symbol keys, ActiveRecord will now translate aliased attribute names to the actual column name used in the database:

With the model

  class Topic
    alias_attribute :heading, :title
  end

The call

  Topic.where(heading: 'The First Topic')

should yield the same result as

  Topic.where(title: 'The First Topic')

This also applies to ActiveRecord::Relation::Calculations calls such as `Model.sum(:aliased)` and `Model.pluck(:aliased)`.

This will not work with SQL fragment strings like `Model.sum('DISTINCT aliased')`.

Github #7839

*Godfrey Chan*

The similarity of `Relation#uniq` to `Array#uniq` is confusing. Since our
Relation API is close to SQL terms I renamed `#uniq` to `#distinct`.

There is no deprecation. `#uniq` and `#uniq!` are aliases and will continue
to work. I also updated the documentation to promote the use of `#distinct`.

Conflicts:
	activerecord/lib/active_record/dynamic_matchers.rb

Nothing should be raised anyway 😄

Thanks @spastorino ❤
https://github.com/rails/rails/pull/8202/files#r2112067

When calling a query method on an attribute that was not selected by
an ActiveRecord query, an ActiveModel::MissingAttributeError is not
raised. Instead, a nil value is returned, which will return false once
cast to boolean.

This is undesirable, as we should not give the impression that we know
the attribute's boolean value when we haven't loaded the attribute's
(possibly) non-boolean value from the database.

This issue is present on versions going back as far as 2.3, at least.

On reflection, it seems like a bit of a weird method to have on
ActiveRecord::Base, and it shouldn't be needed most of the time anyway.

This reverts commit 14fc8b34.

Reason: we need to discuss a better path from this removal.

Conflicts:
	activerecord/lib/active_record/reflection.rb
	activerecord/test/cases/base_test.rb
	activerecord/test/models/developer.rb