This was added in #31727, but it is unused.

Rails has some support for multiple databases but it can be hard to
handle migrations with those. The easiest way to implement multiple
databases is to contain migrations into their own folder ("db/migrate"
for the primary db and "db/seconddb_migrate" for the second db). Without
this you would need to write code that allowed you to switch connections
in migrations. I can tell you from experience that is not a fun way to
implement multiple databases.

This refactoring is a pre-requisite for implementing other features
related to parallel testing and improved handling for multiple
databases.

The refactoring here moves the class methods from the `Migrator` class
into it's own new class `MigrationContext`. The goal was to move the
`migrations_paths` method off of the `Migrator` class and onto the
connection. This allows users to do the following in their
`database.yml`:

```
development:
  adapter: mysql2
  username: root
  password:

development_seconddb:
  adapter: mysql2
  username: root
  password:
  migrations_paths: "db/second_db_migrate"
```

Migrations for the `seconddb` can now be store in the
`db/second_db_migrate` directory. Migrations for the primary database
are stored in `db/migrate`".

The refactoring here drastically reduces the internal API for migrations
since we don't need to pass `migrations_paths` around to every single
method. Additionally this change does not require any Rails applications
to make changes unless they want to use the new public API. All of the
class methods from the `Migrator` class were `nodoc`'d except for the
`migrations_paths` and `migrations_path` getter/setters respectively.

Ensure that `bin/rails db:migrate` with specified `VERSION` reverts
all migrations only if `VERSION` is `0`.
Raise error if target migration doesn't exist.

  When load schema from `structure.sql`, database connection isn't
  established. `ActiveRecord::Tasks::DatabaseTasks.load_schema` has to
  establish database connection since it executes
  ```
  ActiveRecord::InternalMetadata.create_table
  ActiveRecord::InternalMetadata[:environment] = environment
  ```

Fix `bin/rails db:setup` and `bin/rails db:test:prepare` create  wrong ar_internal_metadata's data for a test database.

  Before:
  ```
  $ RAILS_ENV=test rails dbconsole
  > SELECT * FROM ar_internal_metadata;
  key|value|created_at|updated_at
  environment|development|2017-09-11 23:14:10.815679|2017-09-11 23:14:10.815679
  ```

  After:
  ```
  $ RAILS_ENV=test rails dbconsole
  > SELECT * FROM ar_internal_metadata;
  key|value|created_at|updated_at
  environment|test|2017-09-11 23:14:10.815679|2017-09-11 23:14:10.815679
  ```

  Fixes #26731.

This was missed when the frozen string literal pragma was added to this
file because the string is only modified when running in the context of
a full Rails app, which wasn't covered by the test suite.

By making the Rails minitest behave like a standard minitest plugin
we're much more likely to not break when people use other minitest
plugins. Like minitest-focus and pride.

To do this, we need to behave like minitest: require files up front
and then perform the plugin behavior via the at_exit hook.
This also saves us a fair bit of wrangling with test file loading.

Finally, since the environment and warnings options have to be applied
as early as possible, and since minitest loads plugins at_exit, they
have to be moved to the test command.

* Don't expect the root method.

It's likely this worked because we eagerly loaded the Rails minitest plugin
and that somehow defined a root method on `Rails`.

* Assign a backtrace to failed exceptions.

Otherwise Minitest pukes when attempting to filter the backtrace (which
Rails' backtrace cleaner then removes).

Means the exception message test has to be revised too.

This is likely caused by the rails minitest plugin now being loaded for
these tests and assigning a default backtrace cleaner.

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

Because we don't need to load tasks for DBs that we don't use for the current app.
Also, these Tasks classes load AR::Base in their class level, and so immediately kick :active_record on_load hooks.
This used to happen when we were loading tasks, not when we run a task.

Set consistent type cast ENV["VERBOSE"]:
  ENV["VERBOSE"] is true if it not equal "false"

Add stronger assertions to rake migration tasks to make sure the user is providing a numeric VERSION
An empty string was getting converted to version = 0. This would in turn pass the presence check.

Address linting warning

Add test for rake task and refactor code to meet expectations
In particular passing VERSION=0 should not raise an error.

Addressed Comments for PR #28485. Trimmed empty lines + change of wording for error message

Adjust test for change of wording in error message

Change condition to follow rails idioms

(I personally prefer writing one string in one line no matter how long it is, though)

Today `rake db:schema:cache:dump` only supports dumping cache for a
single connection (`ActiveRecord::Base.connection`). This doesn't work
for apps with multiple databases.

This PR makes `DatabaseTasks` to provide an API for dumping schema cache
for any connection.

Without this patch it's impossible to pass extra flags to
mysqldump/pg_dump when running `rake db:structure:dump` or `load`

The following config variables (`structure_load_flags` and `structure_dump_flags`)
make it better configurable.

Some case expressions remain, need to think about those ones.

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

Instead of passing a separete name variable, we can make the resolver
merge a name on the config, and use that before creating the Specification.

Without clearing the caches afterward, removals done in migrations would
not be reflected in a separate task in the same process. That is, given
a table with a migration to remove a column, the schema cache would
still reflect that a table has that in something such as the
'db:seed' task:

`rake db:migrate db:seed`
(A common thing to do in a script for a project ala `bin/setup`)

vs

`rake db:migrate && rake db:seed`
(Two processes)

The first would not reflect that the column was removed.
The second would (cache reset).

This reverts a334425c.

The main reason is that now the workflow is inconsistent when using
spring.

When using spring `RAILS_ENV` is always set, so only one database is
created.

This means that in development `bin/rake db:create` and `bundle exec
rake db:create` have different results.

It also breaks the `bin/setup` script since `bin/rake db:setup
db:test:prepare` will fail.

creating all databases mutates the connection pool.  This patch restores
the connection pool to the connection spec established before creating
all databases.  Fixes #23279

The error message has become a `DISABLE_DATABASE_ENVIRONMENT_CHECK`, modified to match the error message.

ref: https://github.com/rails/rails/blob/master/activerecord/lib/active_record/migration.rb#L161

Discussion: https://github.com/rails/rails/pull/22967#discussion_r49137035

Raise an error when a destructive action is made on a database where the current environment is different from the environment stored in the database.

This PR introduces a key/value type store to Active Record that can be used for storing internal values. It is an alternative implementation to #21237 cc @sgrif @matthewd.

It is possible to run your tests against your production database by accident right now. While infrequently, but as an anecdotal data point, Heroku receives a non-trivial number of requests for a database restore due to this happening. In these cases the loss can be large.

To prevent against running tests against production we can store the "environment" version that was used when migrating the database in a new internal table. Before executing tests we can see if the database is a listed in `protected_environments` and abort. There is a manual escape valve to force this check from happening with environment variable `DISABLE_DATABASE_ENVIRONMENT_CHECK=1`.

Still more to do. Please assist!

* 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.