Fix failing tests

In 04ac5655 I assumed that we would
never want to pass the "table_name.column_name" form to where with a
symbol. However, in Ruby 2.2 and later, you can quote symbols using the
new hash syntax, so it's a semi-reasonable thing to do if we want to
support the dot notation (which I'd rather deprecate, but that would be
too painful of a migration).

Instead we've changed the definition of "this is a table name with a
dot" to when the value associated is a hash. It would make very little
sense to write `where("table_name.column_name": { foo: :bar })` in any
scenario (other than equality for a JSON column which we don't support
through `where` in this way).

Close #24514.

instead of loading the relation into memory

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

Fix `test_find_with_order_on_included_associations_with_construct_finder_sql_for_association_limiting_and_is_distinct` to NULL-agnostic way

The sort order of NULL depends on the RDBS implementation. This commit
is to fix the test to NULL-agnostic way.

Example:

    ```
    activerecord_unittest=# SELECT  DISTINCT "posts"."id", author_addresses_authors.id AS alias_0 FROM "posts" LEFT OUTER JOIN "authors" ON "authors"."id" = "posts"."author_id" LEFT OUTER JOIN "author_addresses" ON "author_addresses"."id" = "authors"."author_address_id" LEFT OUTER JOIN "categorizations" ON "categorizations"."category_id" = "posts"."id" LEFT OUTER JOIN "authors" "authors_posts" ON "authors_posts"."id" = "categorizations"."author_id" LEFT OUTER JOIN "author_addresses" "author_addresses_authors" ON "author_addresses_authors"."id" = "authors_posts"."author_address_id" ORDER BY author_addresses_authors.id DESC;
     id | alias_0
    ----+---------
      1 |
      2 |
      3 |
      4 |
      5 |
      6 |
      7 |
      8 |
      9 |
     10 |
     11 |
      1 |       1
    (12 rows)
    ```

    ```
    root@localhost [activerecord_unittest] > SELECT  DISTINCT `posts`.`id`, author_addresses_authors.id AS alias_0 FROM `posts` LEFT OUTER JOIN `authors` ON `authors`.`id` = `posts`.`author_id` LEFT OUTER JOIN `author_addresses` ON `author_addresses`.`id` = `authors`.`author_address_id` LEFT OUTER JOIN `categorizations` ON `categorizations`.`category_id` = `posts`.`id` LEFT OUTER JOIN `authors` `authors_posts` ON `authors_posts`.`id` = `categorizations`.`author_id` LEFT OUTER JOIN `author_addresses` `author_addresses_authors` ON `author_addresses_authors`.`id` = `authors_posts`.`author_address_id` ORDER BY author_addresses_authors.id DESC;
    +----+---------+
    | id | alias_0 |
    +----+---------+
    |  1 |       1 |
    |  3 |    NULL |
    |  1 |    NULL |
    |  2 |    NULL |
    |  4 |    NULL |
    |  5 |    NULL |
    |  6 |    NULL |
    |  7 |    NULL |
    |  8 |    NULL |
    |  9 |    NULL |
    | 10 |    NULL |
    | 11 |    NULL |
    +----+---------+
    12 rows in set (0.00 sec)
    ```

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.

We currently generate an unbounded number of prepared statements when
`limit` or `offset` are called with a dynamic argument. This changes
`LIMIT` and `OFFSET` to use bind params, eliminating the problem.

`Type::Value#hash` needed to be implemented, as it turns out we busted
the query cache if the type object used wasn't exactly the same object.

This drops support for passing an `Arel::Nodes::SqlLiteral` to `limit`.
Doing this relied on AR internals, and was never officially supported
usage.

Fixes #22250.

We currently generate an unbounded number of prepared statements when
`limit` or `offset` are called with a dynamic argument. This changes
`LIMIT` and `OFFSET` to use bind params, eliminating the problem.

`Type::Value#hash` needed to be implemented, as it turns out we busted
the query cache if the type object used wasn't exactly the same object.

This drops support for passing an `Arel::Nodes::SqlLiteral` to `limit`.
Doing this relied on AR internals, and was never officially supported
usage.

Fixes #22250.

`replace_named_bind_variables` and `replace_bind_variables` are
definded in `sanitization.rb`, so it is reasonable these tests are
on `sanitize_test.rb`.

In this commit, find_by doesn't cache arguments
so that find_by with association subquery works correctly.

Fixes #20817

This reverts commit d5ba9a42, reversing
changes made to 30c50339.

Reason: This generate the dynalic finders more than one time

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

If there is a method defined such as `find_and_do_stuff(id)`, which then
gets called on an association, we will perform statement caching and the
parent ID will not change on subsequent calls.

Fixes #18117

This ensures that we're handling all forms of nested tables the same way.

We're aware that the `convert_dot_notation_to_hash` method will cause a
performance hit, and we intend to come back to it once we've refactored some of
the surrounding code.

[Melissa Xie & Melanie Gilman]

`Computer` class needs to be require

See #17217 for more details

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

For now, we will just skip the cache when a non-column key is used in the hash.
If the future, we can probably move some of the logic in PredicateBuilder.expand
up the chain to make caching possible for association queries.

Closes #16903
Fixes #16884

`User.where(id: [[1,2],3])` was equal to `User.where(id:[1, 2, 3])`
in Rails 4.1.x but because of some refactoring in Arel this stopped
working in 4.2.0. This fixes it in Rails.

[Dan Olson & Cristian Bica]