`where_sql` now requires that we pass it an engine. None of the manager
classes take an engine in their constructor.

We should not behave differently just because a class has a default
scope.

Sufficiently large integers cause `find` and `find_by` to raise
`StatementInvalid` instead of `RecordNotFound` or just returning `nil`.
Given that we can't cast to `nil` for `Integer` like we would with junk
data for other types, we raise a `RangeError` instead, and rescue in
places where it would be highly unexpected to get an exception from
casting.

Fixes #17380

The current style for warning messages without newlines uses
concatenation of string literals with manual trailing spaces
where needed.

Heredocs have better readability, and with `squish` we can still
produce a single line.

This is a similar use case to the one that motivated defining
`strip_heredoc`, heredocs are super clean.

This commit removes the duplication of the error message:

> Couldn't find #{@klass.name} with [#{arel.where_sql}]

introduced in #15791 by adding a private method `find_nth!` that
deals with all the method like `first!` and `second!`.

This is cased by 03118bc5 + 9b5d603c. The first commit referenced the undefined
local variable `column` when it should be using `reflection.type` as the lookup
key. The second commit changed `build_arel` to not modify the `bind_values` in-
place so we need to combine the arel's `bind_values` with the relation's when
building the SQL.

Fixes #16591

Related #15821 / #15892 / 7aeca506

Fixes #15821.

Model that the Record was not found in.

we're guaranteed to pass a numeric value for offset, so if it's zero,
just don't add an offset to the query

please pass the id of the AR object by calling `.id` on the model first.

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

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.

Refs #13658

Closes #7441

Conflicts:
	activerecord/lib/active_record/relation/finder_methods.rb

I don't really like passing the block, but this seems easiest for now

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