IFC-858 Cascade delete with relationship identifiers generated from generics

[gmazoyer]

This PR does not contain a fix yet. However it highlights the issue which is caused by relationship identifiers that will get generated automatically but won't match when a relationship is set at the generic level. This will cause NodeDeleteIndex and NodeDeleteValidator not to pick up the cascade delete and therefore prevent it.

Using the schema given as an example in #4780, the generated relationship identifiers will be:

• testinterface__testinterfaceholder for the interfaces relationship of InfraDevice to InfraInterface
• testdevice__testinterface for the device relationship of InfraInterface to InfraDevice.
  For cascade delete to work the would need to be both identified by either testinterface__testinterfaceholder or testdevice__testinterface but not a mix of both.

There are few potential fixes which will impact the already loaded schemas:

1. Generate or re-generate relationship identifiers after inheritance of nodes have been processed. This will ensure that the identifiers match even if a relationship is set on a generic because its identifier will be generated based on the node and not the generic. The result of this fix is that the relationship identifiers will both be testdevice__testinterface.
2. Have some introspection when generating the identifier at first when generic are involved so identifiers are based on generic kinds. This will most likely require more code than the previous one. The result of this fix (if implementation can be done) will be that relationship identifiers will both be testinterface__testinterfaceholder.
3. Patch the node delete logic to use relationship identifiers as if they were both generated from the generic and the node. This might be less intrusive than the previous propositions but this feels like not fixing the actual issue but one of its side effects. Relationship identifiers in the schema won't change (which is the root cause of the issue).

The first solution seems to be the more appropriate one (from my point of view) but this might have some consequences on existing schemas as relationship identifiers will likely be re-generated.

A temporary workaround for #4780 is also the set the identifiers in the schema file so that they match.

[codspeed-hq]

CodSpeed Performance Report

Merging #5538 will not alter performance

_{Comparing gma-20250121-4780 (d5954f7) with stable (ee9b3e7)}

Summary

✅ 11 untouched benchmarks