Use `Range#cover?` instead of `Range#include?` to check the inclusion of a value in a date time range.

Add AC::TestSession#dig method like AD::Request::Session

Restore previous behavior of parallel test databases

Bump image_processing gem version to fixe ruby 2.7 warnings

This commit is somewhat of a bandaid fix for a bug that was revealed in #38029
and then #38151. #38151 can cause problems in certain cases when an app has
a 3-tier config, with replicas, because it reorders the configuration
and changes the implict default connection that gets picked up.

If an app calls `establish_connection` with no arguments or doesn't call
`connects_to` in `ApplicationRecord` AND uses parallel testing
databases, the application may pick up the wrong configuration.

This is because when the code in #38151 loops through the configurations
it will update the non-replica configurations and then put them at the
end of the list. If you don't specify which connection you want, Rails
will pick up the _first_ connection for that environment. So given the
following configuration:

```
test:
  primary:
    database: my_db
  replica:
    database: my_db
    replica: true
```

The database configurations will get reordered to be `replica`,
`primary` and when Rails calls `establish_connection` with no arguments
it will pick up `replica` because it's first in the list.

Looking at this bug it shows that calling `establish_connection` with no
arguments (which will pick up the default env + first configuration in
the list) OR when `establish_connection` is called with an environment
like `:test` it will also pick up that env's first configuration. This
can have surprising behavior in a couple cases:

1) In the parallel testing changes we saw users getting the wrong db
configuration and hitting an `ActiveRecord::ReadOnlyError`
2) Writing a configuration that puts `replica` before `primary`, also
resulting in a `ActiveRecord::ReadOnlyError`

The real fix for this issue is to deprecate calling
`establish_connection` with an env or nothing and require an explcit
configuration (like `primary`). This would also involve blessing
`:primary` as the default connection Rails looks for on boot. In
addition, this would require us deprecating connection specification
name "primary" in favor of the class name always since that will get
mega-confusing (seriously, it's already mega-confusing).

We'll work on fixing these underlying issues, but wanted to get a fix
out that restores previous behavior.
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.

Defaults content_type to application/octet-stream in blob_record.js

Defaults content_type to application/octet-stream in blob_record.js

[direct_upload_xls_in_chrome]

Prevent NoMethodError on named route in integration test

Allow #nulls_first and #nulls_last in PostgreSQL

Add match 302 http code for log in redirect_to test

Update `open_ended?` to support new Ruby 2.6 endless and Ruby 2.7 beginless ranges

Fix collision check when using a generator and using the force option

Add ActiveRecord::Validations::NumericalityValidator

Add Active Record numericality validator with support for casting
floats using a database columns' precision value.

Only assign @new_record_before_save once in autosave_association

Use full option names in psql / pg_dump for clarity

If we defined a callback before an association that updates the object, then this may end up being
manipulated to being `false` when it should be `true`. We guard this be only defining it once.

The implication of it being false, in this case, is that the children aren't updated with the parent_id
and so they fail to associate to one another.

See https://github.com/rails/rails/issues/38120 for more details

Define mattr_* methods at caller's location

Avoid unnecessary SQL query when calling ActiveRecord::Relation#cache_key

Add `:round_mode` parameter support to number helpers

Fix the broken anchor of link [ci skip]

Support handling a `round_mode` in `ActiveSupport::NumberHelper::RoundingHelper`

Add default value to locale file

Update inline documentation with new parameter option

Update CHANGELOG

Add round_mode examples to all the tests

Add I18n test

Simplify logic

Further simpification

Include primary key in insert_all conflict target if specified

Before:

    [1] pry(main)> $ ActiveJob::Base.default_priority

    From: lib/active_support/core_ext/module/attribute_accessors.rb @ line 64:
    Owner: ActiveJob::QueuePriority::ClassMethods
    Visibility: public
    Number of lines: 3

    def #{sym}
      @@#{sym}
    end

After:

    [1] pry(main)> $ ActiveJob::Base.default_priority

    From: /home/jhawthorn/src/rails/activejob/lib/active_job/queue_priority.rb @ line 9:
    Owner: ActiveJob::QueuePriority::ClassMethods
    Visibility: public
    Number of lines: 1

    mattr_accessor :default_priority

Previously this was incorrectly defining this attribute on the singleton
class, which would end up actually using the class variable from Module.

https://buildkite.com/rails/rails/builds/66168#b348f446-0406-425e-ba53-c5d15034cf98/1002-1070

Fix adding non-null column to existing SQLite3 table