With a multiple database application `db:rollback` becomes problematic.
We can't rollback just the primary, that doesn't match the behavior in
the other tasks. We can't rollback a migration for every database, that
is unexpected.

To solve this I handled `db:rollback` the same way I handled `:up` and
`:down`. If `db:rollback` is called for a multi-db application then it
will raise an error recommending you use `db:rollback:[NAME]` instead.
Calling `db:rollback:primary` or `db:rollback:animals` will rollback
the migration for the number of steps specified.

Closes: #38513
Follow-up to: #34078

This method was jumping through extra hoops to find the name of the
class the connection is stored on when we can get it from the connection
itself. Since we already have the connection we don't need to loop through the
pools.

In addition, this was using the wrong class name. The class name for the
schema migration should come from the connection owner class, not from
the `db_config.name`. In this case, `db_config.name` is the name of the
configuration in the database.yml. Rails uses the class name to lookup
connections, not the db config name, so we should be consistent here.

While working on this I noticed that we were generating an extra schema
migration class for `ActiveRecord::Base`. Since `ActiveRecord::Base` can
and should use the default and we don't want to create a new one for
single db applications, we should skip creating this if the spec name is
`ActiveRecord::Base`. I added an additional test that ensures the class
generation is correct.

If I had had these tests previously I would have not created PR #38658
and then promptly realize I needed to revert it.

We need to load and parse the configurations twice. Once before the
environment is loaded to create the named tasks and once after the
environment is loaded to have the real configurations. The configs
loaded before the env have the ERB stripped out and aren't valid
configs.

Wow this is embarrassing. I literally named this FIXME so I'd remember
to give it some name that made sense and then I totally did not.

I have so. many. regrets. about using `spec_name` for database
configurations and now I'm finally putting this mistake to an end.

Back when I started multi-db work I assumed that eventually
`connection_specification_name` (sometimes called `spec_name`) and
`spec_name` for configurations would one day be the same thing. After
2 years I no longer believe they will ever be the same thing.

This PR deprecates `spec_name` on database configurations in favor of
`name`. It's the same behavior, just a better name, or at least a
less confusing name.

`connection_specification_name` refers to the parent class name (ie
ActiveRecord::Base, AnimalsBase, etc) that holds the connection for it's
models. In some places like ConnectionHandler it shortens this to
`spec_name`, hence the major confusion.

Recently I've been working with some new folks on database stuff and
connection management and realize how confusing it was to explain that
`db_config.spec_name` was not `spec_name` and
`connection_specification_name`. Worse than that one is a symbole while
the other is a class name. This was made even more complicated by the
fact that `ActiveRecord::Base` used `primary` as the
`connection_specification_name` until #38190.

After spending 2 years with connection management I don't believe that
we can ever use the symbols from the database configs as a way to
connect the database without the class name being _somewhere_ because
a db_config does not know who it's owner class is until it's been
connected and a model has no idea what db_config belongs to it until
it's connected. The model is the only way to tie a primary/writer config
to a replica/reader config. This could change in the future but I don't
see value in adding a class name to the db_configs before connection or
telling a model what config belongs to it before connection. That would
probably break a lot of application assumptions. If we do ever end up in
that world, we can use name, because tbh `spec_name` and
`connection_specification_name` were always confusing to me.

If they are not included in this "test types" list, they're counted
towards app code lines, not test lines.

Follow-up to #38463.

By isolating ARGV, we guard against commands inadvertently depending on
prior ARGV contents.  Any such command will now behave consistently when
run via `Rails::Command.invoke`, whether coming from the Rails CLI or
from library code.  Likewise, any ARGV mutations done by a command will
not affect code that executes after `Rails::Command.invoke`.

The schema cache tests test the following scenarios:

1) The default case works (single db, primary spec name (dev is default
to primary in 2-tier config), standard default schema cache filename)
2) Primary always wins over other entries
3) A custom schema cache filename works when set in the configuration
4) A custom schema cache filename works when set in the ENV

Cases that don't work:

1) A non-primary database entry picks up a namespaced schema cache file

This can't work currently because there's no way of knowing which cache
we actually want. In this railtie we can only load ActiveRecord::Base's
schema cache. If we grab the first config we risk loading a cache for
another connection because order is not guaranteed.

2) Multi-db schema caches

The reasons are similar to above. In addition we can't loop through the
configs, establish a connection, and load the cache because we don't
know what parent class to establish a connection to. In that case AR
Base will always get the cache and it would cause the last one to win
and therefore be loaded on the wrong connection.

The real fix for these issues is to get rid of the railtie entirely, but
for now we needed to set this back to what the behavior was before
recent changes but with the ability to pass a custom key.
Co-authored-by: NKatrina Owen <kytrinyx@github.com>

I think allowing nested array parameters is almost useless.

The initializer that loads the default schema cache on the default
connection doesn't account for the case where an app overrides the
default filename either via ENV["SCHEMA_PATH"], or via the
:schema_cache_path defined in the db config.

Note that as discussed in #34449 this initializer doesn't work for
applications using multiple databases, and this change doesn't fix that.

Database configurations are now objects almost everywhere, so we don't
need to fake access to a hash with `#default_hash` or it's alias `#[]`.
Applications should `configs_for` and pass `env_name` and `spec_name` to
get the database config object. If you're looking for the default for
the test environment you can pass `configs_for(env_name: "test", spec_name:
"primary")`. Change test to developement to get the dev config, etc.

`#default_hash` and `#[]` will be removed in 6.2.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

The main interface to eager loading is config.eager_load. The logic that
implies happens during the boot process.

With the introduction of Zeitwerk, application code is loaded in the
finisher as everything else, but in previous versions of Rails users
could eager load the application code regardless of config.eager_load.

Use cases:

   * Some gems like indexers need to have everything in memory and would
   be a bad user experience to ask users to conditionally set the eager
   load flag.

   * Some tests may need to have everything in memory and would be a bad
   experience to have the flag enabled globally in the test environment.

I personally feel that the contract between this method and the entire
eager loading process is ill-defined. I believe this method is
essentially internal. The purpose of this patch is simply to restore this
functionality emulating what it did before because rethinking the design
of this interface may need time.

This reverts commit ed78e964, reversing
changes made to eca6c273.

It's a bit difficult to deal properly with IRB's multi line and color,
and I think we don't need to check it out in `rails console` tests.

Fixes https://github.com/rails/rails/issues/28827.

The steps to reproduce are as follows:

git clone git@github.com:bbuchalter/rails-issue-28827.git
cd rails-issue-28827
bundle install
bin/rails db:create

Observe that we create two databases when invoking db:create: development and test. Now observe what happens when we invoke our drop command while using DATABASE_URL.

DATABASE_URL=sqlite3://$(pwd)/db/database_url.sqlite3 bin/rails db:create

As expected, the development environment now uses the DATABASE_URL. What is unexpected is that the test environment does not.

It's unclear what the expected behavior should be in this case, but the cause of it is this: https://github.com/rails/rails/blob/9f2c74eda07ea5a9e4e624d5575a717714088dbf/activerecord/lib/active_record/tasks/database_tasks.rb#L494

Because of each_local_configuration, there seems to be no way invoke these database rake on only the development environment to ensure DATABASE_URL is respected.

The smallest scope of change I can think to make would be to conditionalize this behavior so it does not get applied when DATABASE_URL is present.

- ### Problem

  ActionPack requires "action_view/base" at boot time, this
  causes a variety of issue that I described in detail in #38024.

  There is no real reason to require av/base in the
  ActionDispatch::Debugexceptions class.

  ### Solution

  Like any other components (such as ActiveRecord, ActiveJob...),
  ActionView::Base shouldn't be loaded at boot time.

  Here are the two main changes needed for this:

  1) Actionview has a special initializer that needs to run
     before the app is fully booted (adding a executor needs to be done
     before application is done booting)
  https://github.com/rails/rails/blob/63ec70e700e321b22e9baf2ad2d45cd3f4febc79/actionview/lib/action_view/railtie.rb#L81-L84

     That initializer used a lazy load hooks but we can't do that anymore
     because Action::Base view won't be triggered during booting process.
     When it will get triggered, (presumably on the first request),
     it's too late to add an executor.

  ------------------------------------------------

  2) Compare to other components, ActionView doesn't use `Base` for
     configuration flag. A lot of flags ares instead set on modules
     (FormHelper, FormTagHelper).
     The problem is that those module depends on AV::Base to be
     loaded, as otherwise configuration set by the user aren't applied.
     (Since the lazy load hooks hasn't been triggered)
     https://github.com/rails/rails/blob/63ec70e700e321b22e9baf2ad2d45cd3f4febc79/actionview/lib/action_view/railtie.rb#L66-L69

     We shouldn't wait for AB::Base to be loaded in order to set these
     configuration. However, we need to do it inside an
     `after_initialize` block in order to let application
     set it to the value they want.

  Closes #28538

  Co-authored-by: betesh <iybetesh@gmail.com>"

We missed these in rails/rails#38005 because deprecation warnings are
silently swallowed by these tests.
Co-authored-by: NJohn Crepezzi <john.crepezzi@gmail.com>

Without this, `Rails.application` returns `nil`.
Ref: https://buildkite.com/rails/rails/builds/65683#e86ec58e-53a5-41be-8aeb-11c5705ee580/1042-1053

Fix: https://github.com/rails/rails/issues/37800

Enabling `SameSite` cookie protection is an addition to CSRF protection,
where cookies won't be sent by browsers in cross-site POST requests when set to `:lax`.

`:strict` disables cookies being sent in cross-site GET or POST requests.

Passing `:none` disables this protection and is the same as previous versions albeit a `; SameSite=None` is appended to the cookie.

See upgrade instructions in config/initializers/new_framework_defaults_6_1.rb.

More info [here](https://tools.ietf.org/html/draft-west-first-party-cookies-07)

_NB: Technically already possible as Rack supports SameSite protection, this is to ensure it's applied to all cookies_

- ### Problem

  ```ruby
    MyJob < ApplicationJob
      before_enqueue { throw(:abort) }
      after_enqueue { # enters here }
    end
  ```
  I find AJ behaviour on after_enqueue and after_perform callbacks
  weird as they get run even when the callback chain is halted.
  It's counter intuitive to run the after_enqueue callbacks even
  though the job wasn't event enqueued.

  ### Solution

  In Rails 6.2, I propose to make the new behaviour the default
  and stop running after callbacks when the chain is halted.
  For application that wants this behaviour now or in 6.1
  they can do so by adding the `config.active_job.skip_after_callbacks_if_terminated = true`
  in their configuration file.

= This feature existed back in 2012 https://github.com/rails/rails/commit/5e7d6bba79393de0279917f93b82f3b7b176f4b5
  but got reverted with the incentive that there was a better approach.
  After discussions, we agreed that it's a useful feature for apps
  that have a really large set of routes.
Co-authored-by: NYehuda Katz <wycats@gmail.com>

This reverts commit 28e44f47.

A limitation of Listen is that it currently only supports watching directories.
Therefore, watching `config/routes.rb` will end up watching the entire `config` directory
if we use the evented file watcher. This causes problems especially if symlinks are present
in the `config` directory.

Co-authored-by: NAllen Hsu <allen.hsusp@gmail.com>