HV-1946 Add an empty path node for iterable/multivalued container elements

[marko-bekhta]

https://hibernate.atlassian.net/browse/HV-1946

[gsmet]

We probably should discuss this patch together as the primary issue was pushing a null value. I'm not sure if we should support that but would need you to refresh my memories :).

Let's try to organize a call soon to discuss that.

[marko-bekhta]

Returning to this one ... since having a null node name passed by a value extractor leads to problems with paths, we could either add a "fake" null node to the path which will serve similarly as, e.g. <iterable element> (used for some built-in ones), or we don't allow nulls and force a value to be passed...
but looking at the spec https://jakarta.ee/specifications/bean-validation/3.1/jakarta-validation-spec-3.1#valueextractordefinition or JavaDocs to be more precise:

• @param nodeName the name of the node representing the container element. If not
  * {@code null}, the name will be used when adding a container element node to the
  * {@link Path}

It means we have to accept the nulls 😕 🫤. Hence we are only left with an option to somehow fix the null case.
I've looked at the patch once more and it seems to make sense. We add a "non-name" node to the path to represent the container element. If we don't have any container element node but are working with container elements, we end up modifying the container node itself, which means that the path becomes incorrect.

Sooooo, I'd suggest merging this in for 9.0 and maybe adding a note to the migration guide stating that the path behaviour now may be different. But maybe you have some other suggestions or ideas for trying to address this case @gsmet @yrodiere ?

[yrodiere]

It's tested, it's compliant with the spec -- that's enough for me.

+1 to merge.