fix infinite recursion with foreign_key

[aharpole]

Motivation / Background

This addresses an infinite recursion that occurs as a result of trying to infer foreign key from an association's inverse_of when two associations are inverses of one another.

Detail

In 15369fd we introduced the ability to infer the foreign_key for a model using inverse_of.

In some association configurations, such as when there is a has_one that is the inverse of another has_one association, this inference causes infinite recursion when calling #foreign_key on the reflection.

This PR addresses that by adding a param to Reflection#foreign_key to indicate whether to infer from inverse_of, and in #derive_foreign_key we explicitly disable this behavior when calling #foreign_key on the inverse association.

Additional information

There didn't appear to be an existing pair of has_one associations that were inverses of one another so I added some to existing models. A pair of has_ones is admittedly a bit odd, but we did encounter such associations in testing.

Checklist

Before submitting the PR make sure the following are checked:

• This Pull Request is related to one change. Changes that are unrelated should be opened in separate PRs.
• Commit message has a detailed description of what changed and why. If this PR fixes a related issue include it in the commit message. Ex: [Fix #issue-number]
• Tests are added or updated if you fix a bug or add a feature.
• CHANGELOG files are updated for the changed libraries if there is a behavior change or additional feature. Minor bug fixes and documentation changes should not be included.

[matthewd]

A pair of has_ones is admittedly a bit odd, but we did encounter such associations in testing.

Hmmm... I'm rather inclined to say that mutual has_one associations are an error. In the example, post_with_inverse really looks like it should be a belongs_to to me.

[kamil-gwozdz]

Hmmm... I'm rather inclined to say that mutual has_one associations are an error. In the example, post_with_inverse really looks like it should be a belongs_to to me.

But then we should raise an exception when we encounter it? Or do we go for the fix from this PR and additionally emit a warning?

[matthewd]

Yeah, that's fair.

I do think it's an abuse of the API to point has_one associations at each other, and more likely points to some need we could provide first-class support for, but upgrading from something that works to something that overflows is not a great experience.

I'm still tempted to do the gentler "no" option and deprecate this arrangement, but especially as it's only detectable when both models are loaded, that seems tricky.

Let's keep things working for now, and then I might revisit whether they should stay working without complaint later.