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

Currently `exists?` does some hackery where it assumes that we can join
onto anything that we passed to `eager_load` or `includes`, which
doesn't work if we are joining onto a polymorphic association.

Actually figuring out if we want to include something would require
knowledge deep within the join dependency module, which is hard to pull
up. The simplest solution is just to pass a flag down that says we're
not actually going to try to eager load any of the data. It's not the
solution I'd like, but that code really needs to be untangled before we
can do much with it.

This is another attempt at 6d5b1fdf which should address the concerns
that led to reverting it in 4ecabed2.

Fixes #25128

Instead of passing a separete name variable, we can make the resolver
merge a name on the config, and use that before creating the Specification.

Ruby 2.4 unifies Fixnum and Bignum into Integer: https://bugs.ruby-lang.org/issues/12005

* Forward compat with new unified Integer class in Ruby 2.4+.
* Backward compat with separate Fixnum/Bignum in Ruby 2.2 & 2.3.
* Drops needless Fixnum distinction in docs, preferring Integer.

If a call to #suppress from the same class occurred inside another #suppress
block, the suppression state would be set to false before the outer block
completes.

This change keeps the previous state around in memory and unwinds it
as the blocks exit.

The error message that we give today makes this error difficult to debug
if you receive it. I have no clue why we're printing the object ID of
the class (the commit doesn't give context), but I've left it as it was
deliberate.

When looking for mutation, we compare the serialized version of the
value to the before_type_cast form. `Type::Serialized` was breaking this
contract by passing the already serialized attribute to the subtype's
mutation detection. This never manifested previously, as all mutable
subtypes either didn't do anything in their `serialize` method, or had a
way to detect double serialization (e.g. `is_a?(String)`). However, now
that JSON types can handle string primitives, we need to avoid double
serialization.

Fixes #24993.

Rails 5.0 has been dropped Ruby 1.9 support.
I think no need magic comment anymore.

When calling remove_connection in a subclass, that should not fallback
to the parent, otherwise it will remove the parent connection from the
handler.

Using ActiveRecord::Base.attribute to declare an attribute with a default value on a model where the attribute is not backed by the database would raise a NotImplementedError when model.save is called.

The error originates from https://github.com/rails/rails/blob/59d252196b36f6afaafd231756d69ea21537cf5d/activerecord/lib/active_record/attribute.rb#L84.
This is called from https://github.com/rails/rails/blob/59d252196b36f6afaafd231756d69ea21537cf5d/activerecord/lib/active_record/attribute.rb#L46 on an ActiveRecord::Attribute::Null object.

This commit corrects the behavior by implementing ActiveRecord::Attribute::Null#type_cast.

With ActiveRecord::Attribute::Null#type_cast defined, ActiveRecord::Attribute::Null#value (https://github.com/rails/rails/blob/59d252196b36f6afaafd231756d69ea21537cf5d/activerecord/lib/active_record/attribute.rb#L173..L175) can be replaced with its super method (https://github.com/rails/rails/blob/59d252196b36f6afaafd231756d69ea21537cf5d/activerecord/lib/active_record/attribute.rb#L36..L40).

fixes #24979

We cannot cache the connection_specification_name when it doesnt
exist. Thats because the parent value could change, and we should keep
failling back to the parent. If we cache that in a children as an ivar,
we would not fallback anymore in the next call, so the children would
not get the new parent spec_name.

remove_connection

When calling `remove_connection` on a model, we delete the pool so we also
need to reset the `connection_specification_name` so it will fallback to
the parent.
This was the current behavior before rails 5, which will fallback to the
parent connection pool.

[fixes #24959]

Special thanks to @jrafanie for working with me on this fix.

If an attribute was of the binary type, and also was a Hash, it would
previously not be logged, and instead raise an error saying that
`bytesize` was not defined for the `attribute.value` (a `Hash`).

Now, as is done on 4-2-stable, the attribute's database value is
`bytesize`d, and then logged out to the terminal.

Reproduction script:

```ruby
require 'active_record'
require 'minitest/autorun'
require 'logger'

ActiveRecord::Base.establish_connection(adapter: 'sqlite3', database: ':memory:')
ActiveRecord::Base.logger = Logger.new(STDOUT)

ActiveRecord::Schema.define do
  create_table :posts, force: true do |t|
    t.binary :preferences
  end
end

class Post < ActiveRecord::Base
  serialize :preferences
end

class BugTest < Minitest::Test
  def test_24955
    Post.create!(preferences: {a: 1})

    assert_equal 1, Post.count
  end
end
```

We are erroring due to nested transaction failures from mysql on test_migrate_clears_schema_cache_afterward test.
Disable transactions for this test.

Fixes #24391

In 5.0 we use bind parameters for limit and offset, while in 4.2 we used
the values directly. The code as it was written assumed that limit and
offset worked as `LIMIT ? OFFSET ?`. Both Oracle and SQL Server have a
different syntax, where the offset is stated before the limit. We
delegate this behavior to the connection adapter so that these adapters
are able to determine how the bind parameters are flattened based on
what order their specification has the various clauses appear.

Fixes #24775

ConnectionHandler will not have any knowlodge of AR models now, it will
only know about the specs.
Like that we can decouple the two, and allow the same model to use more
than one connection.

Historically, folks used to create abstract AR classes on the fly in
order to have multiple connections for the same model, and override the
connection methods.

With this, now we can override the `specificiation_id` method in the
model, to return a key, that will be used to find the connection_pool
from the handler.

[ci skip]

Fix failing tests

Unlike `one?` and `none?`, `empty?` has interactions with methods
outside of enumerable. It also doesn't fit in the same vein.
`Topic.any?` makes sense. `Topic.empty?` does not, as `Topic` is not a
container.

Fixes #24808
Close #24812