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

Perf ref: https://gist.github.com/vipulnsward/8209749201dfdd678c97

In 94924dc3 the internal default_scope
implementation has changed making it simpler to follow, meaning that the
old usage of with_default_scope has been removed.

With that, order_values was the same argument for both calls to
find_first_with_limit, so remove it and use the existent attribute
for the sake of clarity/simplification.

The previous implementation was necessary in order to support stuff
like:

    class Post < ActiveRecord::Base
      default_scope where(published: true)
      scope :ordered, order("created_at")
    end

If we didn't evaluate the default scope at the last possible moment
before sending the SQL to the database, it would become impossible to
do:

    Post.unscoped.ordered

This is because the default scope would already be bound up in the
"ordered" scope, and therefore wouldn't be removed by the
"Post.unscoped" part.

In 4.0, we have deprecated all "eager" forms of scopes. So now you must
write:

    class Post < ActiveRecord::Base
      default_scope { where(published: true) }
      scope :ordered, -> { order("created_at") }
    end

This prevents the default scope getting bound up inside the "ordered"
scope, which means we can now have a simpler/better/more natural
implementation of default scoping.

A knock on effect is that some things that didn't work properly now do.
For example it was previously impossible to use #except to remove a part
of the default scope, since the default scope was evaluated after the
call to #except.

Rather than raising ThrowResult when construct_limited_ids_conditions comes up empty, set the relation to NullRelation and rely on its results.

This will help avoid errors like 2fcafee2, because in most cases NullRelation will do the right thing. Minor bonus is avoiding the use of exceptions for flow control.

In #apply_join_dependency, we can apply the #where in-place because relation is always a new object.

Thanks to the #except we call at the top of the method.