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.

Move the except(:select) inside the construct_limited_ids_condition method to pair it closely with its motivation.

Reject blank order_values within #columns_for_distinct, as the orders aren't used at all on non-postgres adapters.

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.

inverse_of option. I've also refactored the code for raising a
RecordNotFound exception when searching for records with ids.

[ci skip]

Closes #3313

This is already handled by #find, it's a duplicate check, since
find_with_ids is not called from anywhere else.

In the end I think the pain of implementing this seamlessly was not
worth the gain provided.

The intention was that it would allow plain ruby objects that might not
live in your main application to be subclassed and have persistence
mixed in. But I've decided that the benefit of doing that is not worth
the amount of complexity that the implementation introduced.

    User.order("name asc").order("created_at desc")
    # SELECT * FROM users ORDER BY created_at desc, name asc

This also affects order defined in `default_scope` or any kind of associations.

It has been moved to active_record_deprecated_finders.

Use #to_a instead.

`FinderMethods#exists?` finder method now returns *false* with the *false* argument

reflection.

ActiveRecord::FinderMethods#construct_limited_ids_condition will raise
ThrowResult if the limited reflection comes back empty. The other callers
of #construct_limited_ids_condition handle this exception (more specifically,
the callers of construct_relation_for*), but #exists? didn't until now.

This behavior was added in be4ecdcc.

Closes #1139.

Fixes #2553, #1141, #1623 and #2062.

Minimal change to query generation of exists? that makes SQLServer and others happy that do not work without a column alias.
Conflicts:
	activerecord/lib/active_record/relation/finder_methods.rb