Fix @SequenceGeneratorDefinition inheritance, take 1

[mpdude]

#10927 reported that #10455 broke the way how the default @SequenceGeneratorDefinition is created and inherited by subclasses for ID columns using @GeneratedValue(strategy="SEQUENCE").

First, I had to understand how @SequenceGeneratorDefinition has been handled before #10455 when entity inheritance comes into play:

• Entity and mapped superclasses inherit the ID generator type (as given by @GeneratedValue) from their parent classes
• @SequenceGeneratorDefinition, however, is not generally inherited
• ... instead, a default sequence generator definition is created for every class when no explicit configuration is given. In this case, sequence names are based on the current class' table name.
• Once a root entity has been identified, all subclasses inherit its sequence generator definition unchanged.

Why did #10455 break this?

When I implemented #10455, I was mislead by two tests BasicInheritanceMappingTest::testGeneratedValueFromMappedSuperclass and BasicInheritanceMappingTest::testMultipleMappedSuperclasses.

These tests check the sequence generator definition that is inherited by an entity class from a mapped superclass, either directly or through an additional (intermediate) mapped superclass.

The tests expect the sequence generator definition on the entity to be the same as on the base mapped superclass.

The reason why the tests worked before was the quirky behaviour of the annotation and attribute drivers that #10455 was aiming at: The drivers did not report the @SequenceGeneratorDefinition on the base mapped superclass where it was actually defined. Instead, they reported this @SequenceGeneratorDefinition for the entity class only.

This means the inheritance rules stated above did not take effect, since the ID field with the sequence generator was virtually pushed down to the entity class.

In #10455, I did not realize that these failing tests had to do with the quirky and changed mapping driver behaviour. Instead, I tried to "fix" the inheritance rules by passing along the sequence generator definition unchanged once the ID column had been defined.

Consequences of the change suggested here

This PR reverts the changes made to @SequenceGeneratorDefinition inheritance behaviour that were done in #10455.

This means that with the new "report fields where declared" driver mode (which is active in our functional tests) we can not expect the sequence generator definition to be inherited from mapped superclasses. The two test cases from BasicInheritanceMappingTest are removed.

I will leave a notice in #10455 to indicate that the new driver mode also affects sequence generator definitions.

The GH10927Test test case validates the sequence names generated in a few cases. In fact, I wrote this test against the 2.15.x branch to make sure we get results that are consistent with the previous behaviour.

This also means @SequenceGeneratorDefinition on mapped superclasses is pointless: The mapped superclass does not make use of the definition itself (it has no table), and the setting is never inherited to child classes.

Fixes #10927. There is another implementation with slightly different inheritance semantics in #11052, in case the fix is not good enough and we'd need to review the topic later on.

[mpdude]

@beberlei you basically agreed to this, right?

[dragonito]

Is it possible that this adjustment changed the way of autoincrement integer ids? Got problems with my fixtures in this version (my snapshottests failing after every generation). If a use 2.17.2 it works well only in 2.17.3 i got random id data. I use mariadb!