Reduce the number of records loaded when preloading across a `has_one`

Memoize regex when checking missing route keys

When the route definition has parameters, we can supply a regex for
validation purposes:

    get "/a/:b" => "test#index", constraints: { b: /abc/ }, as: test

This regex is going to be used to check the supplied values during
link generation:

    test_path("abc") # check "abc" against /abc/ regex

The link generation code checks each parameter. To properly validate the
parameter, it creates a new regex with start and end of string modifiers:

    /\A#{original_regex}\Z/

This means for each link generation the code stringifies the existing
regex and creates a new one. When a new regex is created, it needs to be
compiled, for large regexes this can take quite a bit of time.

This change memoizes the generated regex for each route when constrains
are given. It also removes the RegexCaseComparator class since it is not
in use anymore.

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.

Although consuming code will almost certainly retraverse this set, we can avoid
walking it twice here. As an extra upside, we can avoid the double-use of an
identity-sensitive hash; this is convenient, because it is another collection we
actually don't need to build.

The Preloader relies on other objects to bind the retrieved records to their
parents. When executed across a hash, it assumes that the results of
`preloaded_records` is the appropriate set of records to pass in to the next
layer.

Filtering based on the reflection properties in `preloaded_records` allows us to
avoid excessive preloading in the instance where we are loading across a
`has_one` association distinguished by an order (e.g. "last comment" or
similar), by dropping these records before they are returned to the
Preloader. In this situation, we avoid potentially very long key lists in
generated queries and the consequential AR object instantiations.

This is mostly relevant if the underlying linked set has relatively many
records, because this is effectively a multiplier on the number of records
returned on the far side of the preload. Unfortunately, avoiding the
over-retrieval of the `has_one` association seems to require substantial changes
to the preloader design, and probably adaptor-specific logic -- it is a
top-by-group problem.

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.