[sharanggupta]

Closes #2417

JdbcDeleteQueryCreator.deleteRelations now skips the paths of entities nested in another entity with an id. The recursion for that entity already deletes them, through the right ids.

The new test in JdbcRepositoryWithCollectionsChainHsqlIntegrationTests fails without the change: a child of the other aggregate loses its grandchildren. The spring-data-relational and spring-data-jdbc unit tests and the HSQL integration tests pass.

[sharanggupta]

@schauder, while looking at #2123 I found that the per-entity recursion in JdbcDeleteQueryCreator.deleteRelations is behind three failures, not one: it reuses the root ids for back references that hold other ids (#2417, this PR), it selects the id column names of the parent from the child table (#2123), and for an entity without an id that has nested collections it builds a sub-select without a select list, so a derived delete over nested Lists fails with IllegalStateException: SELECT does not declare a select list.

Rather than patching the recursion three times, I have a branch that builds the nested deletes in one pass over the aggregate's paths, deepest first, where each delete's condition navigates to the root through a sub-select on the table of every ancestor with an id, the way SqlGenerator.getSubselectCondition does for deleteAll:

main...sharanggupta:spring-data-relational:derived-delete-subselects

It carries the regression tests in JdbcRepositoryWithCollectionsChainHsqlIntegrationTests (this PR's, the CHILD_ID rename you suggested on #2128, nested lists without ids, and read-only children, which derived deletes removed although deleteById keeps them), with foreign keys in the schema so that the deepest-first order is exercised. The full relational and JDBC suites pass on HSQL.

If you prefer that direction I can switch this PR to it, which would close #2123 as well; otherwise this PR stays the minimal fix for #2417 and I can offer the id-column fix separately on #2123.