[ci skip]

Add AC::Parameters tests for WhereChain#not

This commit follows up of 6a6dbb4c.

This commit follow up of 4d8f62dc.
The difference from 4d8f62dc are below:

* Change `WhereClauseFactory` to accept `Arel::Nodes::Node`
* Change test cases of `relation_test.rb`

This reverts commit 4d8f62dc.

Reason: This broke the build. Please recommit again when it is green.

`WhereClauseFactory` handles all other branches based on argument types,
so the code fits more naturally here, and it's just where the
responsibility belongs.

[#20473]

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

The rdoc parser seems to trip on the `private def` construct.
Public methods following a method defined with `private def` are not
visible inside the module docs but are appended to the top-most module.

For example the method `ActiveRecord::QueryMethods#distinct` was listed
under `ActiveRecord#distinct`.

/cc @sgrif

Also unify the format of code example output. Only use `# =>` if the
actual return value is described. Otherwise simply use `#`.

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

`require 'active_support/core_ext/string/filters'` was added in b3bfa361. However, it is no longer needed from 3ae98181.

Fixes #21488

[Sean Griffin & johanlunds]

Sometimes opts passed in might respond to ==, e.g. `Arel::Nodes::Grouping`. In this case, `opts == :chain` returns `Arel::Nodes::Equality` which causes odd behaviour. Prefer `if :chain == opts` which guarantees that `Symbol#==` would be invoked. Alternatively consider `eql?`.

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]

Our general contract in Active Record is that strings are assumed to be
SQL literals, and symbols are assumed to reference a column. If a from
clause is given, we shouldn't include the table name, but we should
still quote the value as if it were a column.

Upon fixing this, the tests were still failing on SQLite. This was
because the column name being returned by the query was `"\"join\""`
instead of `"join"`. This is actually a bug in SQLite that was fixed a
long time ago, but I was using the version of SQLite included by OS X
which has this bug. Since I'm guessing this will be a common case for
contributors, I also added an explicit check with a more helpful error
message.

Fixes #20360

See #9683 for the reasons we switched to `distinct`.

Here is the discussion that triggered the actual deprecation #20198.

`uniq`, `uniq!` and `uniq_value` are still around.
They will be removed in the next minor release after Rails 5.

Example:
  User.left_outer_joins(:posts)
  => SELECT "users".* FROM "users" LEFT OUTER JOIN "posts" ON "posts"."user_id" = "users"."id"

Fix c4794806 to account for from_value -> from_clause in bdc51416

Fix appending table_name to select and group when used with subquery (fr...

    Post.where('id = 1').or(Post.where('id = 2'))
    # => SELECT * FROM posts WHERE (id = 1) OR (id = 2)

[Matthew Draper & Gael Muller]

`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 column is primarily used for type casting, which we're trying to
separate from the idea of a column. Since what we really need is the
combination of a name, type, and value, let's use the object that we
already have to represent that concept, rather than this tuple. No
consumers of the bind values have been changed, only the producers
(outside of tests which care too much about internals). This is
*finally* possible since the bind values are now produced from a
reasonable number of lcoations.

Attempting to grok this code by refactoring it as I go through it.

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.

Contrary to my previous commit message, it wasn't overkill, and led to
much cleaner code.

[Sean Griffin & anthonynavarre]

The last place that was assigning it was when `from` is called with a
relation to use as a subquery. The implementation was actually
completely broken, and would break if you called `from` more than once,
or if you called it on a relation, which also had its own join clause,
as the bind values would get completely scrambled. The simplest solution
was to just move it into its own array, since creating a `FromClause`
class for this would be overkill.

All of its uses have been moved to better places

This fixed an issue where `having` can only be called after the last
call to `where`, because it messes with the same `bind_values` array.
With this change, the two can be called as many times as needed, in any
order, and the final query will be correct. However, once something
assigns `bind_values`, that stops. This is because we have to move all
of the bind values from the having clause over to the where clause since
we can't differentiate the two, and assignment was likely in the form
of:

`relation.bind_values += other.bind_values`

This will go away once we remove all places that are assigning
`bind_values`, which is next on the list.

While this fixes a bug that was present in at least 4.2 (more likely
present going back as far as 3.0, becoming more likely in 4.1 and later
as we switched to prepared statements in more cases), I don't think this
can be easily backported. The internal changes to `Relation` are
non-trivial, anything that involves modifying the `bind_values` array
would need to change, and I'm not confident that we have sufficient test
coverage of all of those locations (when `having` was called with a hash
that could generate bind values).

[Sean Griffin & anthonynavarre]

We've now removed all uses of them across the board. All logic lives on
`WhereClause`.

The code assumes that non-single-value methods mean multi value methods.
That is not the case. We need to change the accessor name, and only
assign an array for multi value methods