All iidm objects properties bearers

[snoopfab]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)
• A PR or issue has been opened in all impacted repositories (if any)

Does this PR already have an issue describing the problem?

Implements #3518

What kind of change does this PR introduce?

What is the current behavior?

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change or deprecate an API?

• Yes
• No

If yes, please check if the following requirements are fulfilled

• The Breaking Change or Deprecated label has been added
• The migration steps are described in the following section

What changes might users need to make in their application due to this PR? (migration steps)

Other information:

[olperr1]

Here are a few comments to begin with.
I still have files to review, but it could allow you to begin taking them into account.

[olperr1]

Having the PropertiesHolder adders is convenient for the deserialization, and even at the object creation via the API, but it may generate a lot of work to support for the custom IIDM implementations maintainers.
Since the deserialization relies on the fact that the adders can have properties, all custom IIDM implementations would have to implement properties support on the adders in order to read v1.15 IIDM networks.

To handle inner elements at deserialization, two mechanisms were introduced for Identifiables:

• in the case the identifiable can be created before reading its inner elements:
  • the SerDe extends AbstractSimpleIdentifiableSerDe
  • the inner elements are read/added to the identifiable after its creation
• in the other case
  • the SerDe extends AbstractComplexIdentifiableSerDe
  • when reading the inner elements, a task is memorized in a List<Consumer<T>>, where T is compatible with the type of the main Identifier to create. Evey task of this list will be later applied on the Identifier once it is created.

These interfaces are only applicable for Identifiers so they could not be used for the new PropertiesHolder objects, but having these 2 mechanisms in mind, it should be possible to have less modifications in the API.

Also note that with the current IIDM implementation, properties are created in the adder only to be copied after in the real object. This have a memory and time overhead.

[olperr1]

Maybe we can think of a mechanism on the adder that allows to memorize tasks that will be automatically added once the object is created.
For instance, an interface for some adders that will have a method to add post-additional tasks that will be automatically applied on the object by the add() method.
If this interface/abstract class can be shared, the change for custom IIDM maintainers will be lighter (and it could be reused later for similar purposes).

[snoopfab]

I agree on the performances overload (time and memory) of storing and setting back properties on adders .
Your idea of a post creation hook that can be called is interresting but i won't have enough time on the subject this week to implement it.

[snoopfab]

I had the time to complete all the other enhancements above

[olperr1]

Thanks @snoopfab!

[olperr1]

Extensions and TopologyModel are not handled by this PR.
But this can maybe be done in another PR?

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
92.6% Coverage on New Code
0.6% Duplication on New Code

See analysis details on SonarQube Cloud