Support partial variants

[antoinebhs]

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)

Does this PR already have an issue describing the problem?
No

What kind of change does this PR introduce?
This PR adds support for partial variant clone.
In the following, we'll use these terms:

• Full variant: A variant that includes all required identifiables and external attributes (e.g., reactive capability curves, temporary limits, etc.).
• Full clone: A clone from a partial or full variant to a full variant.
• Partial variant: A variant that contains only the identifiables and external attributes whose values differ from those in the full variant (or created identifiables/external attributes). To be fully defined, a partial variant must be associated with a full variant, which provides the non-updated identifiables and external attributes. A partial variant cannot exist independently of a full variant.
• a partial clone is a clone from a partial or full variant to a partial variant.

Note: the concept of partial variant as it is implemented assumes (as before) that when a variant is modified, all the "child" variants are deleted and need to be rebuilt.

What is the current behavior?
When cloning a network, all the identifiables and external attributes (reactive capability curves, temporary limits, etc.) are cloned. It leads to long clone time and duplicates unnecessary data in the server.

What is the new behavior (if this is a feature change)?
We add support for partial clone to only save on the server created/updated identifiables or external attributes in partial variants. Most of the logic is implemented in the server.
In the network store, this is done by adding two new network attributes:

• cloneStrategy: specifies the cloning strategy to be used for the network variant
• fullVariantNum: indicates the full variant that the partial variant depends on. For example, if variantNum = 2 is a partial clone of the full variant variantNum = 1, then fullVariantNum = 1 for variantNum = 2. If the variant is a full variant itself, fullVariantNum is set to -1.

In order to change the cloneStrategy, one can:

• use NetworkStoreService.setCloneStrategy() and then use cloneVariant methods of the VariantManager. The server will read the network attributes and clone the variant with the corresponding clone strategy.
• use NetworkStoreService.cloneVariant() with a clone strategy, this will override the clone strategy defined in the network and clone with the strategy given as argument. I'm not sure it's good to have this two ways for cloning with cloneStrategy (set/clone and clone with override). Should we keep the clone strategy as an argument or remove it and also make use of NetworkStoreService.setCloneStrategy() to set the cloneStrategy?
  Note: NetworkStoreService.setCloneStrategy() does a synchronous call to the server to update the network attributes. This is done to make sure that we read the correct clone strategy as cloneVariant are also synchronous.

By default, when creating a network or cloning a network, the clone strategy is always set to partial. This means that if you have N1 with clone strategy full and you full clone it to N2, the clone strategy of N2 will be partial. I did it that way because I consider that full clone are a one time operation and should not be persisted for the next variants. This logic is applied in the server and cached client/buffered client too.

We also added utility methods to bind and update attributes for SV updates (see corresponding code in the server). It simplified the code on the server but I'm not sure it's a good implementation to have this in the client as it does not make much sense. To be discussed.

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

• Yes
• No

Other information:
As we don't implement a way to have a full clone from a partial variant, all variants are partial except the initial variant (variantNum = 0). We can thus see this first implementation as a "diff from initial variant". See further work to see what's missing to have full variant in between partial variants.

Prerequisite for this PR:

• invalidate all nodes (see below on network-modification)

Further work should be done to:

• support full clone from partial variant
  • reconstruct the full variant from a partial variant
  • change or implement some code in the network-modification-server to change its behavior. In particular, we can "Unbuild" any node (equivalent to delete variant in network-store). For example, if N3 is a full variant, N4 is a partial clone of N3. Then, N3 is unbuilt. As N4 depends on the full variant N3, it should be unbuilt too. Similarly to when we modify a node and the child nodes are unbuilt. Or we may want to remove this "Unbuild" feature. That's also why we need to invalidate nodes, to avoid to have full variant that are not the initial variant as this can lead to inconsistencies.
  • see if we want to add an heuristic, let users choose which network should be fully cloned, do it during some computations, etc.

[FranckLecuyer]

Change year

[FranckLecuyer]

Why these 2 static methods bind and update in the client ?
They are only used in the server ...
Same for other *SvAttributes class ...

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
96.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud