Supress Exceptions in some cases when working with variants [ allowVariantMultiThreadAccess(true) ]

[jonenst]

Please check if the PR fulfills these requirements (please use '[x]' to check the checkboxes, or submit the PR and then click the checkboxes)

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)

Does this PR already have an issue describing the problem ? If so, link to this issue using '#XXX' and skip the rest
No

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Bug Fix: This PR supresses Exceptions in some cases when working with variants

What is the current behavior? (You can also link to an open issue here)

• calling allowVariantMultiThreadAccess when the variant was not set was throwing an exception. This can happen if you your removed your variant, or if you are using the multithreaded mode and call allowVariantMultiThreadAccess from a thread where the variant was not set (example Exception when relaunching a security analysis powsybl-gse#201 )
• calling allowVariantMultiThreadAccess(true) would always create a new threadlocal. This meant that all threads with a variant set would lose their currentvariant if one thread called allowVariantMultiThreadAccess(true) again

What is the new behavior (if this is a feature change)?
allowVariantMultiThreadAccess doesn't do anything if we are already in the good mode. allowVariantMultiThreadAccess doesn't throw when the currentvariant is not set (for multithread mode, it keeps it unset; for singlethread mode, it resets the variant to the default variant.

Does this PR introduce a breaking change or deprecate an API? If yes, check the following:
No

Other information:
This is not a perfect solution... This API is very dangerous and we should think about changing it completely. In the meantime, this PR makes it less error prone.

Problems with the current API:
If a network is shared between multiple tasks that are not aware of each other, on task can set allowVariantMultiThreadAccess(false) while the other task is relying on the fact that it had set allowVariantMultiThreadAccess(true) for its computation.
In this case, it is unclear what we want to do:

• synchronize and wait that a task has finished before calling the next ? In the case of servers, this is probably bad because a long running task will block other tasks.
• make allowVariantMultiThreadAccess immutable ? Then this should be in the constructor. But sometimes you don't know when constructing the network if you need multithread access or not.
• Keep only one mode ? If so, we need to keep the multithreaded mode (needed for performance). But then singlethreaded code deals with threadlocals and their dangerous behavior.

[coveralls]

Coverage increased (+0.007%) to 84.183% when pulling 2c89c21 on fixvariants into ed24b0d on master.

[jonenst]

It was proposed to entirely remove the possibility to have an unset variant for the allowMultithreadAccess(false) mode to make things more coherent. @geofjamg what do you think ? (the only possibility to get in this state is to remove the working variant). With the following diff:

diff --git a/iidm/iidm-impl/src/main/java/com/powsybl/iidm/network/impl/MultiVariantContext.java b/iidm/iidm-impl/src/main/java/com/powsybl/iidm/network/impl/MultiVariantContext.java
index a667398aa..2423c2825 100644
--- a/iidm/iidm-impl/src/main/java/com/powsybl/iidm/network/impl/MultiVariantContext.java
+++ b/iidm/iidm-impl/src/main/java/com/powsybl/iidm/network/impl/MultiVariantContext.java
@@ -36,7 +36,7 @@ class MultiVariantContext implements VariantContext {
     @Override
     public void resetIfVariantIndexIs(int index) {
         if (this.index == index) {
-            this.index = -1;
+            this.index = VariantManagerImpl.INITIAL_VARIANT_INDEX;
         }
     }
 }
diff --git a/iidm/iidm-impl/src/main/java/com/powsybl/iidm/network/impl/VariantManagerImpl.java b/iidm/iidm-impl/src/main/java/com/powsybl/iidm/network/impl/VariantManagerImpl.java
index 8c91e94ca..77a592bff 100644
--- a/iidm/iidm-impl/src/main/java/com/powsybl/iidm/network/impl/VariantManagerImpl.java
+++ b/iidm/iidm-impl/src/main/java/com/powsybl/iidm/network/impl/VariantManagerImpl.java
@@ -26,7 +26,7 @@ public class VariantManagerImpl implements VariantManager {
 
     private static final Logger LOGGER = LoggerFactory.getLogger(VariantManagerImpl.class);
 
-    private static final int INITIAL_VARIANT_INDEX = 0;
+    static final int INITIAL_VARIANT_INDEX = 0;
 
     private VariantContext variantContext;
 

[jonenst]

Let's merge this and then we can think about the API of unset variants ?

it was proposed to entirely remove the possibility to have an unset variant for the allowMultithreadAccess(false) mode to make things more coherent. @geofjamg what do you think ? (the only possibility to get in this state is to remove the working variant). With the following diff: