In addition to defining the association, a `required` association will
also have its presence validated.

Before:

```ruby
belongs_to :account
validates_presence_of :account
```

After:

```ruby
belongs_to :account, required: true
```

This helps to draw a distinction between types of validations, since
validations on associations are generally for data integrity purposes,
and aren't usually set through form inputs.

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 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`.

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.

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.

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

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.

This fixes #15496

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

Before:

member.current_membership.club_id # => nil

After:

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

add_constraints is complicated and difficult to read. This is the
beginning of a long process of refactoring this code. First step:
moved the join keys out of AssociationScope and into reflection.

We then don't need to call `reflection` because now reflection is
`self`.

`foreign_key` must be named something else because reflection already has a
`foreign_key` method and when passed into `JoinKeys` it was getting the
wrong assignment. `reflection_foreign_key` seemed to be an appropriate name.
I also named `key` `reflection_key` to match `reflection_foreign_key`.

Reflection has an available method that is used to check if the
reflection is a collection. Any :has_many macro is considered a
collection and `collection?` should be used instead of
`macro == :has_many`.

Instead of checking for `macro == :has_one` throughout the
codebase we can create a `has_one?` method to match the `belongs_to?`,
`polymorphic?` and other methods.

In some cases there is a difference between the two, we should always
be doing one or the other. For convenience, `type_cast` is still a
private method on type, so new types that do not need different behavior
don't need to implement two methods, but it has been moved to private so
it cannot be used accidentally.

Integration tests are inside protected_attributes test suite.

Fixes #15496
Fixes rails/protected_attributes#35

Reflection has a `belongs_to?` method. Instead of checking for
`macro == :belongs_to` throughout the source reuse existing
method.

I also bumped `foreign_key_present?` method onto on line because
the `belongs_to?` makes it shorter than other longer lines in
the same class.

than existing column.

Fixes #15480.

Fix polymorphic to check for `options[:polymorphic]` instead of
`options.key? :polymorphic` and then reuse the method `polymorphic?`
method instead of constantly checking the same `options[:polymorphic]`.

Fix habtm reflection
Conflicts:
    activerecord/CHANGELOG.md
    activerecord/lib/active_record/counter_cache.rb
    activerecord/lib/active_record/reflection.rb
    activerecord/test/cases/reflection_test.rb

The foreign_key could be `String` and just doing `owners_map[owner_key]`
could return `nil`.
To prevent this bug, we should `to_s` both keys if their types are
different.

Fixes #14734.

Fixes #14824.

When delete or destroy is called on all records nothing
is deleted or destroyed. Intead of running through the code and still
not deleteing anything, we should early return

cc:
https://github.com/rails/rails/commit/a11e2fcff8cdc9691b977d8330abe63024f8c732#commitcomment-6353614
and 0369dbfd

parent_name is a string of nil, never a blank string so we don't need to
use presence.

this change was unneccsary as nothing was gained from it

Rename delete_all_records because this name better describes
what the method is doing. We can then remove :all from the
hm:t version and pull out the unoptimized call to load_target
in delete_records and pass it directly.

Refactor delete_count method to only handle delete_all or nullify/nil cases
and not destroy and switch to if/else rather than case statement. This
refactoring allows removal of :all symbol usage.

Refactor by creating two methods delete_all_records and delete_records
to be called by delete_all and delete (or destroy) respectively.
This reduces the number of conditionals required to handle _how_
records get deleted.

The new delete_count method handles how scope is applied to which
delete action.

A delete_all_records method also has to be called in has_many_through
association because of how the methods are chained. This will be
refactored later on.

Thank's for @laurocaetano for the help with tests. 😃

Fixes #14709

Closes #15024.

These operations happen before instances are created.
The current behavior is misleading and can result in broken behavior.

HABTM should fall back to using the normal CollectionAssociation's size calculation if the collection is not cached or loaded.

This addresses both #14913 and #14914 for master.

Rewrite to avoid 'we'/'you', add missing period, and keep lines at 80 chars. Cheers :)

Improve readability with help from @senny

[ci skip]