Define `sanitize_sql_for_order` for AR and use it inside `preprocess_…

This commit follows up of 6a6dbb4c.

Allow bigint with default nil for avoiding auto increment primary key

Such as #10404, #18206.

Remove `DEFAULT_CHARSET` and `DEFAULT_COLLATION`

This reverts commit f6ca7e4e.

The default collation of utf8 in MySQL is the `utf8_general_ci`, and
this should not be changed. This is because, the better collation in the
all locales is not exists, optimal collation in own application is not
known other than themselves.

The `utf8_unicode_ci` is known as Japanese killer in Japan, there are
serious impacts in search of Japanese.

MySQL implements the `utf8_unicode_ci` according to the Unicode
Collation Algorithm (UCA) described at http://www.unicode.org/reports/tr10/,
but the `utf8_unicode_ci` have only partial support for the UCA, only
primary level key comparison implemented (also known as L1 (Base
characters) comparison).

Because L1 (Base characters) comparison does not distinguish between the
presence or absence of the accent, if distinction of the accent is
important there is a serious impact (e.g. Japanese).

Example:

```
> SHOW CREATE TABLE `dicts`\G
*************************** 1. row ***************************
       Table: dicts
Create Table: CREATE TABLE `dicts` (
  `word` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `meaning` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
1 row in set (0.00 sec)

> INSERT INTO `dicts` VALUES ('ハハ', 'mother'), ('パパ', 'father');
Query OK, 2 rows affected (0.00 sec)

> SELECT * FROM `dicts` WHERE `word` = 'ハハ';
+--------+---------+
| word   | meaning |
+--------+---------+
| ハハ   | mother  |
| パパ   | father  |
+--------+---------+
2 rows in set (0.00 sec)

> CREATE UNIQUE INDEX `unique_index_word` ON `dicts`(`word`);
ERROR 1062 (23000): Duplicate entry 'ハハ' for key 'unique_index_word'
```

We should omit the collation entirely rather than providing a default.
Then the choice is the responsibility of the server and MySQL distribution.

Add CHANGELOG entry for #22125 [ci skip]

Move some AR test cases to inheritance_test.rb

Update changelog for #22122

Fix double word 'string' [ci skip]

Route generator should be idempotent

Fix double word 'be' [ci skip]

minor formatting changes [ci skip]

* add newline for display the fenced code block
* add "#" in the comments section

These methods are defined in inheritance.rb

* `abstract_class?`
* `descends_from_active_record?`
* `compute_type`

this allows us to construct mailer objects without possibly disastrous
side-effects.

Alias left_joins to left_outer_joins

Add test for parsing application/vnd.api+json

rails/application: allow passing an env to config_for

we should be using a countdown latch instead of rolling our own
busy-loop.

Make migrations concurrent safe (using advisory locks)

- Addresses issue #22092
- Works on Postgres and MySQL
- Uses advisory locks because of two important properties:
  1. The can be obtained outside of the context of a transaction
  2. They are automatically released when the session ends, so if a
  migration process crashed for whatever reason the lock is not left
  open perpetually
- Adds get_advisory_lock and release_advisory_lock methods to database
  adapters
- Attempting to run a migration while another one is in process will
  raise a ConcurrentMigrationError instead of attempting to run in
  parallel with undefined behavior. This could be rescued and
  the migration could exit cleanly instead. Perhaps as a configuration
  option?

Technical Notes
==============

The Migrator uses generate_migrator_advisory_lock_key to build the key
for the lock. In order to be compatible across multiple adapters there
are some constraints on this key.
- Postgres limits us to 64 bit signed integers
- MySQL advisory locks are server-wide so we have to scope to the
  database
- To fulfil these requirements we use a Migrator salt (a randomly
  chosen signed integer with max length of 31 bits) that identifies
  the Rails migration process as the owner of the lock. We multiply
  this salt with a CRC32 unsigned integer hash of the database name to
  get a signed 64 bit integer that can also be converted to a string
  to act as a lock key in MySQL databases.
- It is important for subsequent versions of the Migrator to use the
  same salt, otherwise different versions of the Migrator will not see
  each other's locks.

This assumes only one query was ever executed, but it appears to
sometimes be loading schema information. We can just look at the array
of queries, rather than the "first" one that was run

When testing cache issues, it is useful to log the actual key, including namespace

added ActiveRecord::Relation#outer_joins

We are using the same version constraint in the database adapters so
when a new version of the adapter that doesn't work with the version of
rails is released we don't break new applications.

This reverts commit 9f93a5ef.

Before this commit, if
`ActiveRecord::Base.belongs_to_required_by_default` is set to `true`,
then creating a record through `has_and_belongs_to_many` fails with the
cryptic error message `Left side must exist`. This is because
`inverse_of` isn't working properly in this case, presumably since we're
doing trickery with anonymous classes in the middle.

Rather than following this rabbit hole to try and get `inverse_of` to
work in a case that we know is not publicly supported, we can just turn
off this validation to match the behavior of 4.2 and earlier.

rather than an action name and *args.  The *args were not being used in regular
applications outside tests.  This causes a backwards compatibility
issue, but reduces array allocations for most users.