Deprecate overriding fields/associations inherited from other entities

[mpdude]

This was brought up in #8348, but seemingly forgotten to be implemented in later versions.

Exact reference:
https://github.com/doctrine/orm/pull/8348/files#diff-732e324167dd49e48b221477c3e0f6d7934f3eb5ec0970dbf1c06f6c7df15398R2261-R2264

Probably never really worked, because a subclass entity cannot have its fields mapped to other columns than the parent entity (just think about what that would mean for STI/JTI, for example).

Closes #10289.

Update #10519 adds the check for associations.

[mpdude]

I am open for suggestions regarding more precise wording.

We don’t care where the field comes from, be it a trait, a mapped superclass or maybe even a transient class.

Key point is that it may not be present in another entity of the same inheritance tree and be overridden for a subclass only.

[mpdude]

How can we make sure not to forget enabling the exception after this is been merged up into 3.0?

[greg0ire]

We have no systematic way of doing that, sadly. We will perform a grep before releasing 3.0.x, but I hope we won't stumble on this contributed by then-unreachable contributors.

[greg0ire]

I'm working on the merge up. While doing so, I noticed a comment similar to the one you changed, that one is in setAssociationOverride, the one you modified in setAttributeOverride.

[mpdude]

Then we should do the same there, x-ref #8348 and /cc @beberlei

[mpdude]

#10520 turns the deprecation notice into an exception in 3.0.x

[mpdude]

#10519 adds the check for associations.