Filter NaN flows from MIP

[pet-mit]

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?

Bug fix

What is the current behavior?

• When sensitivity computation in PRAO fails for a given contingency, a sensitivity failure over-cost is computed, but the flow CNECs of that contingency are still part of the MIP range-action optimization.
  This leads to NaN values in MIP (when sensi computation fails, output reference flow value is NaN) and can crash the RAO.
• When the initial sensitivity computation has a failed state, no overcost is reported

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

• MIP fillers that use the flow variable now filter flow CNECs first, and only retains those with a succeeded sensitivity computation status
• Unfortunately, since the status can change between two sensi iterations, we may have to remove or add variables and constraints. Since removing variables and constraints is not possible in OR-Tools, the linear problem's update method now resets the MIP and calls the "fill" method first
• PR Second preventive RAO: fail if one sensitivity fails #994 has been reverted since it is no longer necessary
• An extra security has been added in OpenRaoMPSolver in order to prevent the MIP from running when there are NaN values added
• When the initial sensitivity computation has a failed state, the overcost is now reported. This means the RAO can prefer RAs that remove network divergence.
• The OpenRaoMPSolver (that uses OR-Tools under the hood) is now used in unit tests, making the tests more representative of real-time execution. However, some numerical tolerances had to be relaxed in consequence
• Also, because we have to reset MIP and call "fill" then "update" when updating now, we cannot access values used in iteration N-1 when in iteration N. Thus MaxLoopFlowFiller and MaxMinMarginFiller cannot keep values from iteration N-1 anymore (when PTDF should not be updated with PSTs). It is assumed that the updated or not values are handled outside the fillers

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

• Yes
• No

Other information

• This patch allows avoiding NaN values while keeping the actual fill / update APIs.
  But it does make updateBetweenSensiIterations almost useless, so we will have to refactor the code to remove all updateBetweenSensi methods and replace them with the creation of all-new problems
• It seems that overamm performance is not really impacted by the re-creation of the optimisation problem between sensi computations. But we'll have to keep an eye on the metrics.