Revert "Revert "Merge pull request #15394 from morgoth/fix-automatic-maintaining-test-schema-for-sql-format""

This reverts commit 5c87b5c5.

This extracts the logic that was embedded in a Rake task into a static
method.
Bonus: the first test for `rake db:migrate`

Revert "Merge pull request #15394 from morgoth/fix-automatic-maintaining-test-schema-for-sql-format"

This reverts commit 46139d33, reversing
changes made to 8f247871.

Conflicts:
	activerecord/CHANGELOG.md

Additionally:
* It changes `purge` task on `sqlite3` adapter to recreate database file, to
be consistent with other adapters.
* Adds `purge` step when loading from `schema.rb`

rather than YAML.load(File.read(path)). YAML.load_file is also used in
guides/rails_guides/helper.rb since 2011, the only other precedent I could find.

Closes #13625

* Move check from generated helper to test_help.rb, so that all
  applications can benefit
* Rather than just raising when the test schema has pending migrations,
  try to load in the schema and only raise if there are pending
  migrations afterwards
* Opt out of the check by setting
  config.active_record.maintain_test_schema = false
* Deprecate db:test:* tasks. The test helper is now fully responsible
  for maintaining the test schema, so we don't need rake tasks for this.
  This is also a speed improvement since we're no longer reloading the
  test database on every call to "rake test".

Warning:

  DEPRECATION WARNING: Passing a string to ActiveRecord::Base.establish_connection for a configuration lookup is deprecated, please pass a symbol (:development) instead.

This commit also cleans up the rake tasks that were checking
for DATABASE_URL in different places.

In fact, it would be nice to deprecate DATABASE_URL usage in the long
term, considering the direction we are moving of allowing those in .yml
files.

This reverts commit 22f80ae5.

See
https://github.com/rails/rails/commit/22f80ae57b26907f662b7fd50a7270a6381e527e#commitcomment-4640676

Conflicts:
	activerecord/CHANGELOG.md

* A non-zero exit status allows subsequent shell commands to be chained
  together such as: `rake db:reset test:prepare && rspec && cap deploy`
  (if you're feeling brave :)
* Any exceptions raised during the `create` and `drop` tasks are caught
  in order to print a "pretty" message to the user. Unfortunately doing
  so prevents rake from aborting with a non-zero exit status to the shell.
* Therefore we re-raise the exceptions after the "pretty" message and
  re-catch them in the task.
* From the task we explicitly exit with a non-zero status. This method
  was chosen (rather than just letting rake fail from the exception) so
  that the backtrace is suppressed and the output to stderr is
  unchanged.
* Update activerecord CHANGELOG

Same as 4d4ff531

It's simpler to assume that passed env is just a string without any
extensions, especially when DatabaseTasks are intended to be used also
without rails.

This is a public class, which could be used directly in order to allow
easier database management. Now it also contains settings, which will be
used by databases.rake.

This will allow to set fixtures path in global config easier, it should
be not needed to use FIXTURES_PATH every time user wants to load
fixtures.

When running tasks such "rake db:setup", instead of showing messages
like "db_development already exists", it was showing a big stack trace
and a message "Couldn't create database for ..." with the configuration
options, a very confusing message with a big trace.

This brings back the functionality present in 3-2, showing the same
message.

- added tests to confirm establish_connection uses DATABASE_URL and
  Rails.env correctly even when no arguments are passed in.
- updated rake db tasks to support DATABASE_URL, and added tests to
  confirm correct behavior for these rake tasks.  (Removed
  establish_connection call from some tasks since in those cases
  the :environment task already made sure the function would be called)
- updated Resolver so that when it resolves the database url, it
  removes hash values with empty strings from the config spec (e.g.
  to support connection to postgresql when no username is specified).

Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in

    https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d

we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.

In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.

In a similar vein to Pat's work on create, drop etc, the db:charset
task is now a one liner in databases.rake