This was accidentally left in, the standard `db:migrate:up` doesn't have
a description so `db:migrate:up:namespace` shouldn't have one either.

Handle up/down for multiple databases

This change adds the ability to run up/down for a database in a multi-db
environment.

If you have an app with a primary and animals database the following
tasks will be generated:

```
VERSION=123 rake db:migrate:up:primary
VERSION=123 rake db:migrate:up:primary

VERSION=123 rake db:migrate:down:primary
VERSION=123 rake db:migrate:up:animals
```

I didn't generate descriptions with them since we don't generate a
description for a single database application.

In addition to this change I've made it so if your application has
multiple databases Rails will raise if you try to run `up` or `down`
without a namespace. This is because we don't know which DB you want to
run `up` or `down` against unless the app tells us, so it's safer to
just block it and recommend using namespaced versions of up/down
respectively.

The output for the raise looks like:

```
You're using a multiple database application. To use `db:migrate:down`
you must run the namespaced task with a VERSION. Available tasks are
db:migrate:down:primary and db:migrate:down:animals.
```

Add `null: false` constraint by default for `belongs_to` associations

This reverts commit f656bb30.

Reason: Test in Action View expects the `collection_cache_key` working...

https://github.com/rails/rails/blob/ff6b713f5e729859995f204093ad3f8e08f39ea8/actionview/test/activerecord/relation_cache_test.rb#L21
https://github.com/rails/rails/blob/ff6b713f5e729859995f204093ad3f8e08f39ea8/actionview/test/fixtures/project.rb#L6

https://buildkite.com/rails/rails/builds/60609#d19181fb-fe80-4d1e-891c-1109b540fb4b/981-1009

- Also deprecate passing {required} to the model generator.
- Also made sure the global config `belongs_to_required_by_default` is
  applied correctly to the model generator for `null: false` option.

handle long or duplicated screenshot filenames

Document algorithm: concurrent option for PostgreSQL [ci skip]

Refactor `ActiveSupport::Deprecation.deprecate_methods` not to expose internal methods

The `collection_cache_key` is private API for a long time, but I've
maintained it in #35848 since it is mentioned in the doc
(https://github.com/rails/rails/pull/35848#discussion_r272011475).

The doc has removed at 1da9a7e4, so there is no longer a reason to
maintain that private API.

Introduce Actionable Errors

In #33325, `deprecate_methods` is replaced from `prepend` to completely
emurated `alias_method_chain`, it exposed two internal methods
`xxx_with_deprecation` and `xxx_without_deprecation`.

After that, #34648 restored the `prepend` implementation, which doesn't
expose any internal methods, so we no longer be able to ensure to always
expose that internal methods.

As I said at https://github.com/rails/rails/pull/33325#issuecomment-409016725,
I think that internal methods exposed is not a specification but a
limitation when using `alias_method_chain`, there is no longer a reason
to follow that limitation.

Adds a warning message for action text installer if application pack …

https://buildkite.com/rails/rails/builds/60601#81daf2ee-9259-42e5-983d-c57d66499b76/928-939

This follows #35595.

This partly reverts 8ca3c286.

`.is_a?(GeneratedAttributeMethodsBuilder)` doesn't make sense to me, the
module class's `new` creates just an instance of the module class itself.

Help command for visible commands should be hidden

```
$ rails --help > tmp/before
$ bundle update rails
...
$ rails --help > tmp/after
$ diff -u tmp/before tmp/after
--- tmp/before	2019-04-19 00:12:08.000000000 -0700
+++ tmp/after	2019-04-19 00:14:55.000000000 -0700
@@ -52,7 +52,6 @@
   db:version
   destroy
   dev:cache
-  dev:help
   encrypted:edit
   encrypted:show
   initializers
```

Actionable errors let's you dispatch actions from Rails' error pages. This
can help you save time if you have a clear action for the resolution of
common development errors.

The de-facto example are pending migrations. Every time pending migrations
are found, a middleware raises an error. With actionable errors, you can
run the migrations right from the error page. Other examples include Rails
plugins that need to run a rake task to setup themselves. They can now
raise actionable errors to run the setup straight from the error pages.

Here is how to define an actionable error:

```ruby
class PendingMigrationError < MigrationError #:nodoc:
  include ActiveSupport::ActionableError

  action "Run pending migrations" do
    ActiveRecord::Tasks::DatabaseTasks.migrate
  end
end
```

To make an error actionable, include the `ActiveSupport::ActionableError`
module and invoke the `action` class macro to define the action. An action
needs a name and a procedure to execute. The name is shown as the name of a
button on the error pages. Once clicked, it will invoke the given
procedure.

The trix moved to a peer dependency since 11b73c40.
So that does not include in `yarn.lock`.

There are four ways to pass the redis option, but only three were
documented. This is now consistent with implementation.

[ci skip]

Preserve html_safe? status on ActiveSupport::SafeBuffer#*

Catch exceptions raised in `parallelize_setup` and ensure tests fail when they occur

Ensure active record can load without Railties

Resolves https://github.com/rails/rails/issues/35835

If an exception occurs during `parallelize_setup` make sure to catch that exception and apply it to the result of each successive test run.  This results in marking all of the tests as failed to bring attention to the issue & ensure it is addressed before proceeding.

When I added the rake tasks for multiple databases I accidentally made
it so you couldn't use Active Record without Railties.

Since getting the database configuration depends on being able to load
Railties (there is no other way to read and parse the yaml file and load
it) I've decided that using multiple databases outside of Rails is a
no-op.

I've changed the code here to return if Rails isn't defined. Then I
changed the other tasks to use `ActiveRecord::Tasks::DatabaseTasks.env`
instead of `Rails.env`. The multi-db tasks can keep using `Rails.env`
because they'll only be generated if we're using Rails and not just
Active Record.

Update Rake to the latest version

Fixes railties ApplicationTests failures in Ruby 2.7.

Rake 12.3.2 includes a [Fix for test fails caused by 2.6 warnings](https://github.com/ruby/rake/pull/297). Upadting prevents failures of:

- `RakeTests::RakeMigrationsTest#test_migration_status_when_schema_migrations_table_is_not_present`
- `RakeDbsTest#test_db:structure:dump_does_not_dump_schema_information_when_no_migrations_are_used`
- `BinSetupTest#test_bin_setup_output`

See [failures log](https://gist.githubusercontent.com/utilum/30e081cc38b5d90e18be8cede6385b10/raw/2b89e568977d4f1fe010726a9a561c10e59c8df8/tests.log).

ruby 2.7.0dev (2019-04-18 trunk 67602) [x86_64-linux]

Mention more ActiveStorage hooks in Active Support Instrumentation guide [ci skip]

Describe how to silence the deprecation warning about empty I18n fall…