Refactor connectivity break analysis to add connectivity loss impact of the contingencies

[p-arvy]

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, but the development is based on the collaborative work of #1169 , aiming to improve the performance of the fast DC SA.
Note that this PR does not directly improve the performance of the fast DC SA but lays the groundwork for it while also improving code quality.

What kind of change does this PR introduce?

The connectivity loss calculation is directly integrated in the class ConnectivityBreakAnalysis, allowing to:

• Improve code quality;
• Refactor the case distinction between contingencies that break connectivity or not in the class WoodburyDcSecurityAnalysis;
• Align the results of the fast DC SA with those of an equivalent load flow (in which the contingencies were applied manually) in the case of a HVDC line without power after the application of a contingency.

Does this PR introduce a new Powsybl Action implying to be implemented in simulators or pypowsybl?

• Yes, the corresponding issue is here
• No

What is the current behavior?

Connectivity results are redundantly obtained in the WoodburyDcSecurityAnalysis class. When the LfContingency object is computed for each contingency (as the SA progresses), the ContingencyConnectivityLossImpact is calculated through a connectivity analysis.

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

The connectivity results (ContingencyConnectivityLossImpact) are integrated in the ConnectivityBreakAnalysis.

This approach allows the use of post-contingency connectivity to determine HVDC lines that end up without power, thus aligning the results of the fast DC SA with those of an equivalent load flow (where contingencies were applied manually).

Additionally, since ConnectivityAnalysisResult objects are used for both cases where a contingency either breaks connectivity or not, there is no longer a need to differentiate between these cases using separate method calls to compute the post-contingency state vector.

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:

[vidaldid-rte]

Promising refactoring.
I think their is however a bug with HVDC loss detection (see coments).
Some other comments.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud