loaded model classes have their connections wrapped in transactions.

See #17776

In Rails 4 config.eager_load was changed to false in the test environment. This
means that model classes that connect to alternate databases with
establish_connection are not loaded at start up. If use_transactional_fixtures
is enabled, transactions are wrapped around the connections that have been
established only at the start of the test suite. So model classes loaded later
don't have transactions causing data created in the alternate database not to
be removed.

This change resolves that by creating a new connection.active_record
notification that gets fired whenever a connection is established. I then added
a subscriber after we set up transactions in the test environment to listen for
additional connections and wrap those in transactions as well.

Caused at a45363a2.

When `group` is used in combination with any calculation method, the
resulting hash uses the grouping expression as the key. Currently we're
incorrectly always favoring the type reported by the query, instead of
the type known by the class. This causes differing behavior depending on
whether the adaptor actually gives proper types with the query or not.
After this change, the behavior will be the same on all adaptors -- we
see if we know the type from the class, fall back to the type from the
query, and finally fall back to the identity type.

Fixes #25595

The documentation states that parameter values longer than 20 characters
will be truncated by words, but the example shows that a parameter based
on "David Heinemeier Hansson" (with id: 125) becomes "125-david" when
"David Heinemeier".length == 16 so why so short?

The answer lies in the use of the #truncate option omission: nil which
seems to have been intended to mean "nothing", but which actually causes
the default string "..." to be used. This causes #truncate to cleave
words until the "..." can be added and still remain within the requested
size of 20 characters.

The better option is omission: '' (which is probably what was originally
intended).

Furthermore, since the use of #parameterize will remove non-alphanumeric
characters, we can maximize the useful content of the output by calling
parameterize first and then giving truncate a separator: /-/ rather than
a space.

     as this can lead to confusing time stubbing.

     Instead of:

         travel_to 2.days.from_now do
           # 2 days from today
           travel_to 3.days.from_now do
             # 5 days from today
           end
         end

     preferred way to achieve above is:

         travel_to 2.days.from_now
         # 2 days from today

         travel_back
         travel_to 5.days.from_now
         # 5 days from today

Closes #24690
Fixes #24689

This reverts commit 407e0ab5.

If you had a foreign key set and then decided to add `on_delete:
:cascade` later in another migration that migration would run but
wouldn't refresh the schema dump.

The reason for this was because `create_table_info` caches the statement
and sets it to be the same as the original declaration for the foreign
key (without the `on_delete: :cascade`.

PR #25307 ended up fixing this bug because it removes the check for
`create_table_info` and relies on reading from `information_schema`. The
fix however was intended to patch another bug. The reason this fixes the
issue is we're no longer parsing the regex from the cached
`create_table_info`.

This regression test is to ensure that the issue does not return if we
for some reason go back to using `create_table_info` to set the foreign
keys.

Because causing an extra query by `sql_for_insert` for guessing a
primary key.
https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/connection_adapters/postgresql/database_statements.rb#L121-L125

Do not specal case inspecting associated arrays of over 10 elements, preventing infinite looping in some cases.

This method appears to have been partially used in connection pool
caching, but it was introduced without much reasoning or any tests. One
edge case test was added later on, but it was focused on implementation
details. This method is no longer used outside of tests, and as such is
removed.

This was added at c7c3f73f but it never raised because MySQL cannot
create text/blob columns with a default value.

If you only want the last element of a result set, there's no need to create all
of hash_rows. Also, add a test.

When you only need the first element of a result set, you shouldn't need to
instantiate all of hash_rows.

- `with_exclusive_scope` was removed in this commit d242e467

Currently `Type::Date#serialize` does not cast a value to a date object.
It should be cast to a date object for finding by date column correctly
working.

Fixes #25354.

`FinderMethods#exists?` should return a boolean rather than raising an
exception.

`UniquenessValidator#build_relation` catches a `RangeError` because it
includes type casting due to a string value truncation. But a string
value truncation was removed at #23523 then type casting in
`build_relation` is no longer necessary. aa062318 removes type casting in
`build_relation` then a `RangeError` moves to `relation.exists?`.

This change will remove the catching a `RangeError`.

Before we enable query caching we check if the connection is
connected. Before this fix we were always checking against the main
connection, and not the model connection.

`construct_relation_for_association_calculations` pass a string value to
`construct_join_dependency` when setting a string value in `from`.
It should not pass a string value, but always `joins_values`.

Related #14834, #19452.

Fixes #24193.

`assert_date_from_db` was added at 6a2104d7 for SQL Server.
But latest sqlserver adapter work to pass expected behavior since
8e4624be.

These comments were added at dd257a3c
but outdated since #2086.

This code was added in 81286f85, but was
not used by that commit and does not appear to have ever been used.

Fixes #25300.

Sqlite3 test failure is due to 66ebbc49.

We were declaring  in a few tests, which depending of
the order load will cause an error, as the super class could change.

see https://github.com/rails/rails/commit/ac1c4e141b20c1067af2c2703db6e1b463b985da#commitcomment-17731383

As part of refactoring mutation detection to be more performant, we
introduced the concept of `original_value` to `Attribute`. This was not
overridden in `Attribute::Uninitialized` however, so assigning ot an
uninitialized value and calling `.changed?` would raise
`NotImplementedError`.

We are using a sentinel value rather than checking the result of
`original_attribute.initialized?` in `changed?` because `original_value`
might go through more than one node in the tree.

Fixes #25228

Currently CI is broken due to 56a61e0c and c4cb6862. This occurred because
the failures are not present on SQLite which is what I normally run
locally before pushing.

The optimizations to our YAML size were dropping mutations, as
`with_type` didn't set the previous value if it'd already been read
(that method was never really designed to be used with values on
individual objects, it was previously only used for defaults). I'm
questioning whether there's a better place to be handling the exclusion
of the type, but this will fix the failing build.

Additionally, there was a bug in `remove_foreign_key` if you passed it
an options hash containing `to_table`. This now occurs whenever removing
a reference, as we always normalize to a hash.

[Sean Griffin & Ryuta Kamizono]

add active record uniqueness validation test for { on: [:create, :update] } condition.

This reduces the size of a YAML encoded Active Record object by ~80%
depending on the number of columns. There were a number of wasteful
things that occurred when we encoded the objects before that have
resulted in numerous wins

- We were emitting the result of `attributes_before_type_cast` as a hack
  to work around some laziness issues
- The name of an attribute was emitted multiple times, since the
  attribute objects were in a hash keyed by the name. We now store them
  in an array instead, and reconstruct the hash using the name
- The types were included for every attribute. This would use backrefs
  if multiple objects were encoded, but really we don't need to include
  it at all unless it differs from the type at the class level. (The
  only time that will occur is if the field is the result of a custom
  select clause)
- `original_attribute:` was included over and over and over again since
  the ivar is almost always `nil`. We've added a custom implementation
  of `encode_with` on the attribute objects to ensure we don't write the
  key when the field is `nil`.

This isn't without a cost though. Since we're no longer including the
types, an object can find itself in an invalid state if the type changes
on the class after serialization. This is the same as 4.1 and earlier,
but I think it's worth noting.

I was worried that I'd introduce some new state bugs as a result of
doing this, so I've added an additional test that asserts mutation not
being lost as the result of YAML round tripping.

Fixes #25145

The code incorrectly assumes that the option was written as
`foreign_key: true`, but that is not always the case. This now mirrors
the behavior of reverting `add_foreign_key`. The code was changed to use
kwargs while I was touching it, as well.

This could really use a refactoring to go through the same code paths as
`add_refernce` in the future, so we don't duplicate default values.

Fixes #25169

Prior to this change, we would get collisions if Active Record objects
of different classes with the same ID were used as keys of the same
hash. It bothers me slightly that we have to allocate inside of this
method, but Ruby doesn't provide any way to hash multiple values without
allocation

Follow up of #20815.

```ruby
class CreatePeople < ActiveRecord::Migration[5.0]
  def change
    create_table :people do |t|
      t.integer :int
      t.bigint :bint
      t.text :txt
      t.binary :bin
    end
  end
end
```

Result.

In postgresql and sqlite3 adapters:

```ruby
ActiveRecord::Schema.define(version: 20160531141018) do

  create_table "people", force: :cascade do |t|
    t.integer "int"
    t.bigint  "bint"
    t.text    "txt"
    t.binary  "bin"
  end

end
```

In mysql2 adapter:

```ruby
ActiveRecord::Schema.define(version: 20160531141018) do

  create_table "people", force: :cascade, options: "ENGINE=InnoDB DEFAULT CHARSET=utf8mb4" do |t|
    t.integer "int"
    t.bigint  "bint"
    t.text    "txt",  limit: 65535
    t.binary  "bin",  limit: 65535
  end

end
```

After this patch:

```ruby
ActiveRecord::Schema.define(version: 20160531141018) do

  create_table "people", force: :cascade, options: "ENGINE=InnoDB DEFAULT CHARSET=utf8mb4" do |t|
    t.integer "int"
    t.bigint  "bint"
    t.text    "txt"
    t.binary  "bin"
  end

end
```

This behavior was broken by 36e9be85. When the value is assigned
directly, either through mass assignment or directly assigning a hash,
the hash gets passed through to this writer method directly. While this
is intended to handle certain cases, when an explicit converter has been
provided, we should continue to use that instead. The positioning of the
added guard caused the new behavior to override that case.

Fixes #25210