We have several test cases on "tricky" types that are essentially
testing that `update_all` goes through the same type casting behavior as
a normal assignment + save. We recently had another case to add this
test for another type in https://github.com/rails/rails/pull/12742.

Rather than testing this separately for every type which is "tricky"
when round tripping, let's instead have a fairly exhaustive test that
ensures we're getting the correct values at every step for `update_all`.
Given the structure of the code now, we can be confident that if the
type is correct, and `update_all` is type casting correctly, we're going
to get the right behavior for all types.

Reliant on https://github.com/rails/rails/pull/15747 but pulled to a
separate PR to reduce noise. `has_many :through` associations have the
undocumented behavior of automatically detecting counter caches.
However, the way in which it does so is inconsistent with counter caches
everywhere else, and doesn't actually work consistently.

As with normal `has_many` associations, the user should specify the
counter cache on the `belongs_to`, if they'd like it updated.

This allows using polymorphism for the uninitialized attributes raising
an exception behavior.

This will make it less painful to add additional properties, which
should persist across writes, such as `name`.

Conflicts:
	activerecord/lib/active_record/attribute_set.rb

Moved `Builder` to its own file, as it started looking very weird once I
added private methods to the `AttributeSet` class and the `Builder`
class started to grow.

Would like to refactor `fetch_value` to change to

```ruby
self[name].value(&block)
```

But that requires the attributes to know about their name, which they
currently do not.

This is a partial fix for #15853. It only works when a `preload`
is issued and not an `eager_load`. I've added a skipped failing
test-case to keep in mind that we need to deal with `eager_load`.

We previously only did this if the old value was zero, to make sure
numericality validations run and failed if the user gave 'wibble' as the
value, which would be type cast to 0. However, numericality validations
will fail if there are any non-numeric characters in the string, so 5 ->
'5wibble' should also be marked as changed.

This is public API, and `simple_form` depends on the `nil` return value.
We need to go through a deprecation cycle to return a null object. If
people want hash access, they can access the hash.

There is a class method with the same name that is tested, but not the
instance method.

`reload` is meant to put a record in the same state it would be if you
were to do `Post.find(post.id)`. This means we should fully replace the
attributes hash.

Attempting to reduce the number of places that care about the details of
how type casting occurs. We remove the type casting of the primary key
in `JoinDependecy`, rather than encapsulating it. It was originally
added for consistency with
https://github.com/rails/rails/commit/40898c8c19fa04442fc5f8fb5daf3a8bdb9a1e03#diff-06059df8d3dee3101718fb2c01151ad0R211,
but that conditional was later removed in
https://github.com/rails/rails/commit/d7ddaa530fd1b94e22d745cbaf2e8a5a34ee9734.

What is important is that the same row twice will have the same value
for the primary key, which it will.

Mostly delegation to start, but we can start moving a lot of behavior in
bulk to this object.

Now the following case will work fine

    class Tag < ActiveRecord::Base
    end

    class Publisher::Article < ActiveRecord::Base
      has_and_belongs_to_many :tags
    end

Fixes #15761

We're never going to be able to use the attribute object here, however,
so let's just accept the ugly demeter violation here for now.

Remove test cases which were either redundant with other tests in the
file, or were actually testing the type objects (which are tested
elsewhere)

Also takes a step towards supporting types which use a character other
than ',' for the delimiter (`box` is the only built in type for which
this is the case)

If we want to have type decorators mess with the attribute, but not the
column, we need to stop type casting on the column. Where possible, we
changed the tests to test the value of `column_defaults`, which is
public API. `Column#default` is not.

HStore columns come back from the database separated by a comma and a
space, not just a comma. We need to mirror that behavior since we
compare the two values.

Also adds a regression test against JSON to ensure we don't have the
same bug there.

If the through record gets created in an `after_create` hook that is
defined before the association is defined (therefore after its
`after_create` hook) get saved twice. This ensures that the through
records are created only once, regardless of the order of the hooks.

This refactoring revealed the need for another form of decoration, which
takes a proc to select which it applies to (There's a *lot* of cases
where this form can be used). To avoid duplication, we can re-implement
the old decoration in terms of the proc-based decoration.

The reason we're `instance_exec`ing the matcher is for cases such as
time zone aware attributes, where a decorator is defined in a parent
class, and a method called in the matcher is overridden by a child
class. The matcher will close over the parent, and evaluate in its
context, which is not the behavior we want.

Before, calling `size` would only work if it skipped the cache, and
would return a different result from the cache, but only if:

- The association was previously loaded
- Or you called size previously
- But only if the size was 0 when you called it

This ensures that the counter is appropriately updated in memory.

We've stopped using it internally, in favor of polymorphism. So should
you!

Fixes #15705.

member = Member.new(club: Club.new)
member.save!

Before:

member.current_membership.club_id # => nil

After:

member.current_membership.club_id # => club's id

We have several mutable types on Active Record now. (Serialized, JSON,
HStore). We need to be able to detect if these have been modified in
place.