This still isn't as separated as I'd like, but it at least moves most of
the burden of alias mapping in one place.

This reverts commit 9f3730a5, reversing
changes made to 2637fb75.

There are additional issues with this commit that need to be addressed
before this change is ready (see #23377). This is a temporary revert in
order for us to have more time to address the issues with that PR,
without blocking the release of beta2.

instead of loading relation

@bogdan pointed out that a `loaded?` relation would not warn that the supplied
offset would be removed. This fixes that oversight.

https://github.com/rails/rails/commit/16a476e4f8f802774ae7c8dca2e59f4e672dc591#commitcomment-15706834

Although this second argument is probably not widely used, and would be
ignored anyway in the loaded? case, this could protect callers from gotchas.

[Ben Woosley & Victor Kmita]

I realized that `first(2)`, etc. was unnecessarily querying for the
records when they were already preloaded. This was because
`find_nth_with_limit` can not know which `@records` to return because
it conflates the `offset` and `index` into a single variable, while
the `@records` only needs the `index` itself to select the proper
record.

Because `find_nth` and `find_nth_with_limit` are public methods, I
instead introduced a private method `find_nth_with_limit_and_offset`
which is called internally and handles the `loaded?` checking.

Once the `offset` argument is removed from `find_nth`,
`find_nth_with_limit_and_offset` can be collapsed into
`find_nth_with_limit`, with `offset` always equal to `offset_index`.

All uses of the `offset` are passing `offset_index`. Better to push
down the `offset` consideration into `find_nth`.

This also works toward enabling `find_nth_with_limit` to take
advantage of the `loaded?` state of the relation.

We know the query will return exactly one row for each entry in the
`ids` array, so we can do all the limit/offset calculations on that
array, in advance.

I also split our new ordered-ids behaviour out of the existing
`find_some` method: especially with this change, the conditionals were
overwhelming the actual logic.

This reverts commit 6d5b1fdf.

`eager_load` and `references` can include hashes, which won't match up
with `references`

A test case has been added to demonstrate the problem

This was changed in 421c81bd, as `exists?` blows up if you are eager
loading a polymorphic association, as it'll try to construct a join to
that table. The previous change decided to execute a `count` instead,
which wouldn't join.

Of course, the only time we actually need to perform a join on the eager
loaded values (which would perform a left outer join) is if they're
being referenced in the where clause. This doesn't affect inner joins.

The focus of this change is to make the API more accessible.
References to method and classes should be linked to make it easy to
navigate around.

This patch makes exzessiv use of `rdoc-ref:` to provide more readable
docs. This makes it possible to document `ActiveRecord::Base#save` even
though the method is within a separate module
`ActiveRecord::Persistence`. The goal here is to bring the API closer to
the actual code that you would write.

This commit only deals with Active Record. The other gems will be
updated accordingly but in different commits. The pass through Active
Record is not completely finished yet. A follow up commit will change
the spots I haven't yet had the time to update.

/cc @fxn

ActiveRecord::RecordNotFound modified to store model name, primary_key
and id of the caller model. It allows the catcher of this exception to make
a better decision to what to do with it. For example consider this simple
example:

    class SomeAbstractController < ActionController::Base
      rescue_from ActiveRecord::RecordNotFound, with: :redirect_to_404

      private def redirect_to_404(e)
        return redirect_to(posts_url) if e.model == 'Post'
        raise
      end
    end

After discussing, we've decided it makes more sense to include it. We're
already forwarding every conflicting method to `to_a`, and there's no
conflation of concerns. `Enumerable` has no mutating methods, and it
just allows us to simplify the code. No existing methods will have a
change in behavior. Un-overridden Enumerable methods will simply
delegate to `each`.

[Sean Griffin & bogdan]

do not change the order of the result if the object was already ordered by the user via :order clause

Stems from https://github.com/rails/rails/pull/20105#issuecomment-100900939
where @senny said:

> From my point of view, all the docs (guides, API) are version bound.
> They should describe that version and continue to be available when newer versions are released.
> The cross referencing can be done by the interested user.

Now that master points at Rails 5, we might not need to explain how
things used to work in Rails 3. Or we might… up to you 😁

It fixes the strange error saying undefined method `take'.

```
RelationTest#test_find_by_without_arg_behaves_same_with_find_by({}):
NoMethodError: undefined method `take' for #<ActiveRecord::QueryMethods::WhereChain:0x007f9c55db1d68>
```

association

While joining table of has_many :through association, ActiveRecord will
use the actual table name instead of through-join alias. It results with
a wrong SQL and exception is raised. This only happens when calculation
methods like #count is called.

This issue is affecting Rails 4.1.x and 4.2.x as well.

Removed non-standard and unused require 'active_support/deprecation' from parts out of active_support.

`bound_attributes` is now used universally across the board, removing
the need for the conversion layer. These changes are mostly mechanical,
with the exception of the log subscriber. Additional, we had to
implement `hash` on the attribute objects, so they could be used as a
key for query caching.

The bind values can come from four places. `having`, `where`, `joins`,
and `from` when selecting from a subquery that contains binds. These
need to be kept in a specific order, since the clauses will always
appear in that order. Up until recently, they were not.

Additionally, `joins` actually did keep its bind values in a separate
location (presumably because it's the only case that people noticed was
broken). However, this meant that anything accessing just `bind_values`
was broken (which most places were). This is no longer possible, there
is only a single way to access the bind values, and it includes joins in
the proper location. The setter was removed yesterday, so breaking `+=`
cases is not possible.

I'm still not happy that `joins` is putting it's bind values on the
Arel AST, and I'm planning on refactoring it further, but this removes a
ton of bug cases.

Fixes #18632

Part of the larger refactoring to remove type casting from Arel.

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