* Add Relation#pick as short-hand for single-value plucks

This is a regression caused by 6beb4de7.

In PostgreSQL, ORDER BY expressions must appear in SELECT list when
using DISTINCT.

When using `count(:all)` with eager loading, Active Record enforces
DISTINCT to count the driving table records only. 6beb4de7 was caused the
regression because `count(:all)` with DISTINCT path no longer removes
ORDER BY.

We need to ignore ORDER BY when DISTINCT is enforced, otherwise not
always generated valid SQL for PostgreSQL.

Fixes #31783.

Currently `count(:all)` with `distinct` doesn't work correctly because
SELECT list is always replaced to `*` or primary key in that case even
if having custom SELECT list.

And also, PostgreSQL has a limitation that ORDER BY expressions must
appear in select list for SELECT DISTINCT.

Therefore, we should not replace custom SELECT list when using
`count(:all)` with `distinct`.

Closes #31277.

This is the fix for the regression of #29848.

In #29848, I've kept existing select list in the subquery for the count
if ORDER BY is given. But it had accidentally affect to GROUP BY
queries also. It should keep the previous behavior in that case.

Fixes #30886.

`to_i` was added for SQLite3 adapter which did not handle number
but sqlite3 gem already supports it then `to_i` is unnecessary.

else condition is kept for adapters which return string,
i.e. mysql(not mysql2) and sqlserver.

Renamed `test_cache_does_not_wrap_string_results_in_arrays`
to `test_cache_does_not_wrap_results_in_arrays` to explain the
current behavior. most of adapters return integer, not only string.

* Refer these commits:

"future proofing the sqlite3 adapter code"
https://github.com/rails/rails/commit/beda2d43d6ac5c3435fc2fba0cbd108c20fe1c67

"Refactor calculation test to remove unneeded SQLite special case."
https://github.com/rails/rails/commit/47d568ed3fc701934ebe80b276f3d8bf6951c93f

"no need to to_i, sqlite does that for us"
https://github.com/rails/rails/commit/6cf44a1bd64ba10497742d70ad78fe68faa16e99

Since #26972, `ORDER BY` is kept if `LIMIT` is presented for
performance. But in most SQL servers (e.g. PostgreSQL, SQL Server, etc),
`ORDER BY` expressions must appear in select list for `SELECT DISTINCT`.
We should not replace existing select list in that case.

The `find_each`, `find_in_batches` and `in_batches` APIs usually operate
on large numbers of records, where it's preferable not to load them all
into memory at once.

If the query cache is enabled, it will hold onto the query results until
the end of the execution context (request/job), which means the memory
used is still proportional to the total number of records. These queries
are typically not repeated, so the query cache isn't desirable here.

This reverts commit 3420a145, reversing
changes made to afb66a5a.

Without this, test fails because the load schema when pluck is executed.

Steps to reproduce:

```
bin/test -a postgresql -w --seed 61689 test/cases/*test.rb -n "/^(?:InheritanceComputeTypeTest#(?:test_inheritance_new_with_subclass_as_default)|CalculationsTest#(?:test_pluck_loaded_relation))$/"

# Running:

.F

Failure:
CalculationsTest#test_pluck_loaded_relation [/home/yaginuma/program/rails/master_y_yagi/rails/activerecord/test/cases/calculations_test.rb:722]:
1 instead of 0 queries were executed.
Queries:
SELECT c.relname FROM pg_class c LEFT JOIN pg_namespace n ON n.oid = c.relnamespace WHERE n.nspname = ANY (current_schemas(false)) AND c.relname = 'companies' AND c.relkind IN ('r','v','m').
Expected: 0
  Actual: 1

bin/test test/cases/calculations_test.rb:7
```

Deprecate passing arguments and block at the same time to `count` and `sum` in `ActiveRecord::Calculations`

`select`, `count`, and `sum` in `Relation` are also `Enumerable` method
that can be passed block. `select` with block already doesn't take
arguments since 4fc3366d. This is follow up of that.

Support for using `SELECT` column or expression aliases in the `HAVING`
clause isn't part of the SQL standard so it's better to whitelist the
test for adapters where we know it works and skip it on others.

Follow up #28183

```
% ARCONN=postgresql be ruby -w -Itest test/cases/calculations_test.rb -n test_apply_distinct_in_count
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/core_ext/enumerable.rb:20: warning: method redefined; discarding old sum
Using postgresql
Run options: -n test_apply_distinct_in_count --seed 27731

F

Finished in 0.163682s, 6.1094 runs/s, 30.5470 assertions/s.

  1) Failure:
CalculationsTest#test_apply_distinct_in_count [test/cases/calculations_test.rb:238]:
Expected /\ASELECT(?! DISTINCT) COUNT\(DISTINCT\b/ to match "SHOW max_identifier_length".

1 runs, 5 assertions, 1 failures, 0 errors, 0 skips
```

https://travis-ci.org/rails/rails/jobs/205493811#L1933
https://travis-ci.org/rails/rails/jobs/205496299#L1562
https://travis-ci.org/rails/rails/jobs/205514765#L1562

When a grouped calculation contains a having clause that references a
selected value, we need to include that selected value in the query.

Postgres doesn't support referencing a selected value in a having
clause, but other databases do; we can skip the test on the pg adapter
but run it for the others.

This was fixed before in 9a298a16, but
the test coverage was lost in 5a05207d.
The fix regressed in 6311975f and was
removed in 97d46c17.

`DISTINCT` clause is applied inside aggregate function by
`operation_over_aggregate_column` if needed. Unneeded outside aggregate
function.

```ruby
  # Before
  author.unique_categorized_posts.count
  # => SELECT DISTINCT COUNT(DISTINCT "posts"."id") FROM "posts" INNER JOIN "categorizations" ON "posts"."id" = "categorizations"."post_id" WHERE "categorizations"."author_id" = ?  [["author_id", 2]]

  # After
  author.unique_categorized_posts.count
  # => SELECT COUNT(DISTINCT "posts"."id") FROM "posts" INNER JOIN "categorizations" ON "posts"."id" = "categorizations"."post_id" WHERE "categorizations"."author_id" = ?  [["author_id", 2]]
```

Closes #27615

This reverts commit 28977f1f.

If select clause is specified and last column has a column alias,
additional column alias causes a statement invalid.

Add test coverage for counting a single column with NULL values.

Fixes #27676, #27682, and #27705.

Refer a similar pull request #26370

Currently `NumericData` model is defined some places.

assert [1, 3].includes?(2) fails with unhelpful "Asserting failed" message

assert_includes [1, 3], 2 fails with "Expected [1, 3] to include 2" which makes it easier to debug and more obvious what went wrong

Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces

Fix all violations in the repository.

The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.

Caused at a45363a2.

When `group` is used in combination with any calculation method, the
resulting hash uses the grouping expression as the key. Currently we're
incorrectly always favoring the type reported by the query, instead of
the type known by the class. This causes differing behavior depending on
whether the adaptor actually gives proper types with the query or not.
After this change, the behavior will be the same on all adaptors -- we
see if we know the type from the class, fall back to the type from the
query, and finally fall back to the identity type.

Fixes #25595

Follow up to #22642.