Try again with OSI 0.108.5

If keeping Gurobi, test it in Github actions: issue972

We decided against adding support for Gurobi for now. 
If there is interest later, we can reopen this.

> > It would also be interesting to test if the objective sense workaround
> > for Soplex is still necessary.
>
> The relevant issue is issue752.

Yes, the SoPlex issue was resolved in this version as well. I modified the comment.

> It would also be interesting to test if the objective sense workaround
> for Soplex is still necessary.

The relevant issue is issue752.

Is there a way of testing the OSI version inside the planner and abort if people select Gurobi with an OSI version that is not recent enough?

Unfortunately, I think a new OSI issue should mean new experiments with *all* LP solvers. We've been bitten in the past.

It would also be interesting to test if the objective sense workaround for Soplex is still necessary. If not, I would still leave it in (for old OSI users), but update the comment to say that this is fixed OSI 0.108.5.

That was quick. OSI 0.108.5 fixes the issue. I'll set up a new experiment when I
get around to installing the new OSI version.

There is another issue with testing this: the OSI interface to Gurobi has a bug
that causes Gurobi to crash when an LP is reloaded
(https://github.com/coin-or/Osi/issues/124). This doesn't affect
operator-counting heuristics that modify the LP instead of reloading it, but it
does affect the optimal landmark heuristics.

There is a simple fix but if we want to advertise Gurobi as a supported solver,
we should wait until that fix makes it into the next OSI release.

When working on issue752 and issue925, I remembered that we now have a Gurobi
module on the grid. So far our local licenses only supported a single concurrent
run, so we were never able to run experiments with Gurobi and treated it as
untested/use-at-your-own-risk. Now we can actually write a find script for it
and test it.