This reverts commit 60c97012, reversing
changes made to 6a25202d.

Reason: Broken build

This triggers the JoinDependency work to reflect on the associations
and trigger an error as follows:

  ActiveRecord::ConfigurationError: Association named 'account' was
  not found on Company; perhaps you misspelled it?

Fix Company.of_first_firm joins association name

Should be `Company.joins(:accounts)` not `Company.joins(:account)`.

Do the same for Client.of_first_firm

Also move the method to the right class

`#exec_stmt` is private method and only called in `#exec_query`. it
means `binds` is provided always. No need `binds.empty?` checking.

* less arrays created
* less complexity with only one level of nesting in loop

* When tried to use `Company#accounts` test/models/company.rb I got:

```
ActiveRecord::StatementInvalid: SQLite3::SQLException: no such column:
accounts.company_id: SELECT COUNT(*) AS count_all, "companies"."firm_id"
AS companies_firm_id FROM "companies" INNER JOIN "accounts" ON
"accounts"."company_id" = "companies"."id" GROUP BY "companies"."firm_id"
```

* The refactor on Calculations class was just to simplify the code

Closes #21922

Let `Book(id, author_id)`, `Photo(id, book_id, author_id)` and `Author(id)`

Running `Book.group(:author_id).joins(:photos).count` will produce:

* Rails 4.2 - conflicts `author_id` in both projection and group by:
```sql
SELECT COUNT(*) AS count_all, author_id AS author_id
  FROM "books" INNER JOIN "photos" ON "photos"."book_id" = "books"."id"
 GROUP BY author_id
```

* Master (9d02a25d) - conflicts `author_id` only in projection:
```sql
SELECT COUNT(*) AS count_all, author_id AS author_id
  FROM "books" INNER JOIN "photos" ON "photos"."book_id" = "books"."id"
 GROUP BY "books"."author_id"
```

* With this fix:
```sql
SELECT COUNT(*) AS count_all, "books"."author_id" AS books_author_id
  FROM "books" INNER JOIN "photos" ON "photos"."book_id" = "books"."id"
 GROUP BY "books"."author_id"
```

This issue was resolved by #21687 already. But re-add args by #18856.
`#tables` extra args was only using by `#table_exists?`. This is for
internal API. This commit will remove these extra args again.

The getter is doing nothing more than returning the ivar, so it can be
extracted to an attr_reader.

[ci skip]

It's been a source of confusion that the lower-level `add_column`
referenced the higher level `column` method for available options.
`column` supports additional functionality like `index: true` that is
not present on `add_column`.

This patch moves common option documentation to `add_column` and only
documents the additional options in `column`.

* If the drop task fails for a reason other than the database not
  existing, processing should end. This is indicated by a non-zero
  exit status.
* Since the backtrace is already printed to screen, we forgo
  printing it again by using an explicit call to `exit`.
* ⚠ This modifies the behavior of the db:create task slightly in
  that the stack trace is no longer printed by default. If the `--trace`
  option is used, it will print the trace _after_ the error message.

* If the create task fails for a reason other than the database already
  existing, processing should end. This is indicated by a non-zero exit
  status.
* Since the backtrace is already printed to screen, we forgo printing it
  again by using an explicit call to `exit`.
* ⚠ This modifies the behavior of the db:create task slightly in
  that the stack trace is no longer printed by default. If the `--trace`
  option is used, it will print the trace _after_ the error message.

* Previously the sqlite3 adapter could not "fail" on drop. Now an error
  is raised when no file exists.
* Also updates purge to be resilient of drop failures. This is how purge
  is expected to behave.

I messed up the merge conflict, and accidentally removed a schema query
that needed to be ignored.

Column names inserted via `group` have to be qualified with table name.

I've been writing too much Rust. My mind is still in the mode of things
being auto-namespaced based on the file...

Prior to this commit, Rails makes no differentiation between whether a
query uses bind parameters, and whether or not we cache that query as a
prepared statement. This leads to the cache populating extremely fast in
some cases, with the statements never being reused.

In particular, the two problematic cases are `where(foo: [1, 2, 3])` and
`where("foo = ?", 1)`. In both cases we'll end up quoting the values
rather than using a bind param, causing a cache entry for every value
ever used in that query.

It was noted that we can probably eventually change `where("foo = ?",
1)` to use a bind param, which would resolve that case. Additionally, on
PG we can change our generated query to be `WHERE foo = ANY($1)`, and
pass an array for the bind param. I hope to accomplish both in the
future.

For SQLite and MySQL, we still end up preparing the statements anyway,
we just don't cache it. The statement will be cleaned up after it is
executed. On postgres, we skip the prepare step entirely, as an API is
provided to execute with bind params without preparing the statement.

I'm not 100% happy on the way this ended up being structured. I was
hoping to use a decorator on the visitor, rather than mixing a module
into the object, but the way Arel has it's visitor pattern set up makes
it very difficult to extend without inheritance. I'd like to remove the
duplication from the various places that are extending it, but that'll
require a larger restructuring of that initialization logic. I'm going
to take another look at the structure of it soon.

This changes the signature of one of the adapter's internals, and will
require downstream changes from third party adapters. I'm not too
worried about this, as worst case they can simply add the parameter and
always ignore it, and just keep their previous behavior.

Fixes #21992.

When `require 'active_support/rails'`, 'active_support/deprecation'
is automatically loaded.

With `unscope!` called last, it undoes `where` constraints of the same
value when the `where` is chained after the `unscope`. This is what a
`rewhere` does. This is undesirable behavior.

The included tests demonstrate both the `unscope(...).where(...)`
behavior as well as the direct use of `rewhere(...)`.

This is in reference to #21955.

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]