Add pre-processing to coinstallability checks

[AltGr]

Addresses some remaining costly cases in #4311

The patch includes a small reorganisation of OpamSolver, but the general
idea is to fix the performance regression compared to 2.0:

• with the introduction of solver invariants, the pre-processing that trimmed
  packages conflicting with the base in OpamState was removed
• it was replaced by something much more general (and reliable) at the
  OpamCudf level
• but only for calls to the external solver, until now

NOTE: this enforces the invariant even for opam install --coinstallable-with, which is consistent with 2.0 but had changed in 2.1.
Without it we can't really expect reasonable performance in general anyway.

[AltGr]

Test case:

opam list -s --depends-on minios-xen.0.7 --coinstallable-with minios-xen.0.7 --rec

from 5+ minutes on master to 12s here

[AltGr]

You can start reviewing, but hold on a little more before merging, I found a bug. Shouldn't be anything big.

[AltGr]

Fixed!

[AltGr]

Squeezed in a one-line fix for #4135

[AltGr]

coinstallability with a non-existent version used to return nothing. Now it returns what would be compatible with that version, which seems more useful

[AltGr]

coinstallable now implies installable (like in 2.0). The intersection was empty, so empty results here.

[AltGr]

Squeezed in a one-line fix for #4135

Actually dropped that, it wasn't needed ; I will comment further on #4135

See the actual diff on opam list outputs here

[gasche]

@Armael and myself hit performances issues in OpamSolver.installable when re-running Marracheck after rebasing on the opam master (last time was a while ago, we were working with something 2.0-ish). We call it to get the set of installable packages in a switch with just a compiler installed. The call would previously take seconds (we don't know how much exactly, but it was fast enough that we didn't even bother to log it) and it now takes around seven minutes on my machine.

We warmly welcome progress on this :-)

[Armael]

FWIW, in marracheck we run OpamSolver.installable on a universe corresponding to a freshly installed switch (containing only the base compiler).
On opam/master this takes 14 minutes (!) on my machine; with this PR it does not seem to be much faster and takes 13 minutes.

[kit-ty-kate]

@Armael what is your switch invariant in your use-case?

[Armael]

I have invariant: [ "ocaml-base-compiler" {= "4.13.1"} ] (in .opam/theswitch/.opam-switch/switch-config)

[rjbou]

note from dev meeting: installable is not directly impacted by this PR (coinstallable is) . Better merge and see how it's going for this one.

[AltGr]

Indeed, this reimplements OpamSolver.installable_subset but doesn't change OpamSolver.installable; I assume the latter could be implemented from the former, but I didn't change it right away to go incrementally (they are bound to different Dose functions underneath, but these should be semantically equivalent).

So it's normal that you don't get a speedup yet; as a benchmark you could try installable_subset with all packages as argument, where the switch invariant will be used for trimming and you should benefit from the optimisation already.