These methods are PostgreSQL-specific, and all supported versions of
PostgreSQL support validating constraints.

Add support for `NOT VALID` check constraints in PostgreSQL

Active Record already supports adding `NOT VALID` foreign key constraints in PostgreSQL, but back in #31323 when check constraint support was initially added, the ability to add a check constraint and validate it separately was not included. This adds that functionality!

Anchor BacktraceCleaner gem filter regexp

This ensures the default gem filter does not affect backtrace lines that
have a subpath incidentally matching a gem path.

Fixes #40196.

Closes #40187.

Update Gemfile.lock with rubocop-packaging

Load Rails tasks for each new Rake::Application

Follow-up to #40185.

Follow-up to #40143.

Rails Rake tasks are loaded for each new `Rake::Application` instance
via `Rails.application.load_tasks`.  However, under the hood,
`Rails.application.load_tasks` used `require` instead of `load`, which
caused Rails tasks to be loaded for only the first `Rake::Application`
instance.

This commit changes the relevant `require` to `load`.

Fixes #40184.

Update RuboCop to v0.90

Signed-off-by: NUtkarsh Gupta <utkarsh@debian.org>

Add explain to abstract database statements.

Support reversing of Arel expressions in reverse_order, last etc.

Shorten inspect on ActionDispatch::Request

Shorten inspect on AbstractController::Base

Calling self in an action of a controller generates an endless stream of
characters, including the request object and all instances variables.
This can be frustrating when using a debugger in a controller and
accidentally calling `self` generates output for a couple of seconds.

This shortens inspect to only show the class name.

    MyController.new.inspect # => "#<MyController:0x00000000005028>"

Calling request in an action of a controller generates an endless stream of
characters, including the Rack app and middlewares.
This can be frustrating when using a debugger in a controller and
accidentally calling `request` generates output for a couple of seconds.

Inspect on ActionDispatch::Request is shortened to the most relevant
attributes and uses the same format as used for request in the logs:

    "#<ActionDispatch::Request POST "https://example.com/path/of/some/uri?q=1" for 1.2.3.4>"

Reduce allocations in expanded_version and expanded_key

Disconnect connections used for acquiring advisory lock in migration.

Raise error when `from` is used with `delete_all`.

Avoid setting `ActiveRecord::Base.configurations` twice in db rake ta…

This prevents the `from` query method from being ignored silently in the
resulting SQL query that is generated.

The current behaviour of reverse_order, when presented with an
existing order that is an Arel expression, is to ignore it.
This isn't quite in keeping with how it handles Arel attributes
(which it reverse) or arbitrary strings (which throw an exception).

The easy path would be to throw an exception, but we don't have to.
Any SQL expression that is a valid default sort expression can be
reversed with DESC.

It follows that if there's an existing Arel::Nodes::NodeExpression
that is not already wrapped with an Arel::Nodes::Ordering, then
it can be reversed with DESC.

When ActiveRecord is used with Rails, loading `ActiveRecord` will set
the configurations so there is no need to do it twice.

Prefer bin/rails for the credentials command

Clarify that exists? and find look in the table, not the unsaved collection [ci skip]

Default db_config should be primary or first

The handling for single database applications has always set a schema.rb
or structure.sql files for loading the database schema. When we first
implemented multiple database support we intended to keep this for the
original, default database. Afterall Rails _has_ to connect to something
on boot. In development only one connection is connected on boot since
we don't eager load the app.

Originally we had thought that all applications should be required to
add a `primary` entry in the database configurations file. However,
this hasn't worked in practice and we have some code now that does not
assume there's a primary. The schema dumping/loading code however,
still assumed there was a "primary" in the configurations file.

We want the "default" database in any application to use the original
files even when converted to a multiple database application as this
reduces the need to make changes when implementing this functionality on
an existing application.

The changes here update Rails to ensure that we treat either "primary"
or the first database configuration for an environment as "default".
If there is a "primary" that will be used as the default configuration.
If there is no primary the configuration that is first for an
environment will be used as the default. For schema dump/load this means
that the default configuration (primary or first) will use `schema.rb`
as the filename and other configurations will use
`[CONFIGURATION_NAME]_schema.rb`.

This should also help us finish the pull request to infer migrations
paths since now we can say the first configuration is the default. This
is a natural assumption for application developers.

Followup to #39536

Fix strange sentence in classic_mode guide [skip ci]

The following sentence doesn't make sense:

  But using `autoload_paths` on its own  in the past (before Rails 5)
  developers might configure `autoload_paths` to add in extra locations...

This changes it to the following:

  Before Rails 5 developers might configure `autoload_paths` to add in
  extra locations...

It also formats the text to use shorter line lengths.

Don't override module name on AV::Base subclass

Use real_mod_name on check for removed module in classic autoloader

We should avoid overriding name if possible because it is confusing to
developers and it also can causes bugs in code which deal with modules
but aren't using the Module.instance_method(:name).bind workaround.

I believe we can achieve the desired "method missing" behaviour by just
redefining inspect.

Refs https://github.com/rails/rails/pull/39819

Previously this check could break if `name` was overridden on the module
we were checking.

Guard against the case where ActiveStorage.verifier isn't yet initialized at load time.

Yes, you're not supposed to load AR models in initializers, but it's easy to do accidentally as long as we don't prevent it. We should be resilient against it wherever practical.