Avoid slack distribution to fictitious loads

[caioluke]

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)

What kind of change does this PR introduce?

Feature.

What is the current behavior?

Currently, LfLoads do not have the method isFictitious like LfGenerators do. Therefore, when distributing slack on loads, we do not take into account if its fictitious or not.

What is the new behavior (if this is a feature change)?
Avoid slack distribution to fictitious loads.

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

• Yes
• No

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarCloud

[annetill]

Applying a contingency:

for (var e : lostLoads.entrySet()) {
    LfLoad load = e.getKey();
    LfLostLoad lostLoad = e.getValue();
    PowerShift shift = lostLoad.getPowerShift();
    load.setTargetP(load.getTargetP() - getUpdatedLoadP0(load, balanceType, shift.getActive(), shift.getVariableActive()));
    load.setTargetQ(load.getTargetQ() - shift.getReactive());
    load.setAbsVariableTargetP(load.getAbsVariableTargetP() - Math.abs(shift.getVariableActive()));
    lostLoad.getOriginalIds().forEach(loadId -> load.setOriginalLoadDisabled(loadId, true));
}

Here, the idea is to remove the effect of a load on a bus. If the load is fictitious, be careful:

• Is the shift ok for a fictitious load, knowing that the variable part is used for slack distribution.
• The updated load P0 that reflects the slack bus distribution on pre-contingency state must adapted?
• The abs variable targetP must be adapted?
  If you prefer, you can do a unit test on a LfNetwork and applying a contingency and check the values. See LfNetworkTest.

Same analysis must be done for actions.