Improve run_gurobi to wait for available token

[tgi-climact]

When using a Gurobi floating token server license or a web single-use license, a program that calls Gurobi Optimizer must obtain a token from a Gurobi token server before it can solve an optimization model. When no token is available, an exception gurobipy.GurobiError is raised (source : https://support.gurobi.com/hc/en-us/articles/360029879251-How-do-I-check-the-availability-of-floating-license-tokens).

To avoid Gurobi Optimizer throwing an error, I suggest to optionally wait for an available token. This is the purpose of this PR. The waiting time (in seconds) can be configured in the solver options.

Side note : This enables scenarios in PyPSA-Eur.

[codecov]

Codecov Report

Attention: Patch coverage is 20.00000% with 12 lines in your changes are missing coverage. Please review.

Project coverage is 86.40%. Comparing base (a6f2c3e) to head (59e1aa1).

Files	Patch %	Lines
linopy/solvers.py	20.00%	10 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #281      +/-   ##
==========================================
- Coverage   89.71%   86.40%   -3.31%     
==========================================
  Files          16       16              
  Lines        4024     4024              
  Branches      941      943       +2     
==========================================
- Hits         3610     3477     -133     
- Misses        281      421     +140     
+ Partials      133      126       -7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[FabianHofmann]

thanks @tgi-climact, perhaps 60 secs is a bit long?

[tgi-climact]

thanks @tgi-climact, perhaps 60 secs is a bit long?

Depending on the optimisation in progress, it could be very long or very short. I would like to avoid spam on the Gurobi servers. What would be your suggestion?

[FabianHofmann]

Depending on the optimisation in progress, it could be very long or very short. I would like to avoid spam on the Gurobi servers. What would be your suggestion?

okay I see, then the 60 secs make sense I guess.

[dannyopts]

A couple of thoughts:

There are many other things that can go wrong when creating an environment, not just token aquisition, for example:
GurobiError: Server aborted the SSL handshake
For this reason, I would atleast log the error, and not assume that it is the token causing failure.

Similarly, I would increase the logging level from debug, since if you are stuck in this loop, it would be helpful to see it in logs than just hang - most production systems only log info level and debug logs are only logged at when you are investigating a bug.

Also I would personally prefer it not to infinitely retry. I think it makes more sense to try some number of times and then give up (throw an error) unless very explicitly told otherwise. I'm imagining a fleet of servers all in a busy loop trying to reach a non-existent gurobi token server and having to all be rebooted.