Bugfix association loading behavior when counter cache is zero

[bogdan]

Suppose we have a has_many association with a counter cache.
In this case, when counter cache is zero, it is often used to avoid certain SQL queries.

Example:

Reward.belogns_to :coupon, counter_cache: true
coupon = Coupon.create!
coupon.rewards_count # => 0 - required

coupon.rewards.size # => 0 no query
coupon.rewards.to_a # => [] no query

However, this behavior doesn't happen consistently. If we change the method call order the number of SQL queries is different:

coupon.rewards.to_a # => [] with query
coupon.rewards.size # => [] no query

It happens because #size makes use of the counter cache and assumes the association is loaded when it is zero. I think that this behavior should be consistent with direct association loading.

A lot of additional tests were added to ensure no regression occur.

cc @kamipo

[rafaelfranca]

There is a random failure being caused by the new tests being added. Can you fix it?

[Edouard-chin]

👋 Thanks for opening this PR ! We are targeting HEAD in our monolith and found that this commit is breaking few of our tests.
TL;DR Model.destroy_all doesn't do anything when fixtures gets loaded and the parent try to destroy all children, this is because the counter_cache_value is 0 when fixtures gets loaded, we end up not loading the target https://github.com/rails/rails/pull/35127/files#diff-7eee2aa7b5cdbffb0bc3ef2eb7d0b76fR70

Although the counter_cache value not getting set seems to be an issue only in tests, isn't it risky that if for any reasons the counter_cache is desync we can end up not deleted any records?

I created a reproduction script here https://gist.github.com/Edouard-chin/df15e2f11a9129880d264c8d861a11ae