Support v8.7

[MartinBelthle]

Problem Statement

We should support new solver version: v8.7

Definition of done

Definition of "done" d'une nouvelle version du Simulateur:

• Mise à jour des numéros de version dans la liste déroulante de la fenêtre de lancement (front office)
• Mettre à jour la documentation dans Antares Launcher (data/README.md) et les tests unitaires ‒ optionel
• Mise à jour des scripts de lancement sur le dépôt antares-cd (launchAntares.sh & launchAntaresRec.sh)
• Template d'étude vide resources/empty_study_new_version.zip et variable STUDY_REFERENCE_TEMPLATES 
• Script d'upgrade des études antarest/study/storage/study_upgrader/upgrader_new_version..py 
• Version par défaut d'une nouvelle étude, variable : NEW_DEFAULT_STUDY_VERSION
• Ajouter les nouveaux paramètres d'entrée
  • Back office
  • Front office
• Ajouter les nouvelles données de sortie: Nouvelles colonnes, Titre, Unités
  • Back office
  • Front office
• Mise à jour du script de packaging package_antares_web.sh
• Tester l’application Desktop (En particulier AntaresWeb.exe)
• Tester l’application standalone Antares_Launcher (Antares_Launcher.exe)
• Mettre à jour la documentation AntaREST

Any potential roadblocks or concerns

Les commandes concernant les bindingconstraints semblent être compliquées à gérer.
En effet, avant la 8.7 une bindingconstraint possède seulement une matrice, puis 3 après la 8.7.
Or les commandes create_binding_constraint et update_binding_constraint héritent toutes 2 d'une classe abstraite AbstractBindingConstraintCommand qui comporte un attribut values représentant l'actuelle unique matrice de la bindingconstraints.
Pour supporter les 3 nouvelles matrices, plusieurs solutions existent:

1. Refactoring de cet attribut pour qu'il puisse aussi accepter un dictionnaire du type {"lt": matrix, "gt": other_matrix ...}. Cela implique de réduire la validation de ce champ car pouvant prendre plus de valeurs.
   J'ai essayé de coder cela mais c'est très compliqué je trouve.
   Notamment car si le champ values n'est pas précisé, il est actuellement rempli par le validateur. Or, celui-ci ne connaît pas la version de l'étude et donc ne sait pas quelle matrice créer.
   Il faudrait faire du refactoring à ce niveau.
   Cela pose la question de quoi faire si la personne renseigne un dictionnaire pour une étude avant la 8.7 et inversement.

2. Ajouter des attributs lt, gt, eq dans la classe abstraite.
   Permet de garder une validaton plus stricte des matrices.
   Nécessite de bien documenter ce changement pour l'utilisation de l'API, et une actualisation des scripts R.
   De plus, cela pose la question de ce qu'on fait si l'utilisateur renseigne le champ values pour une étude de version inférieure à la 8.7 ou inversement avec les champs lt etc.