Avoid downgrading root packages as much as possible when using the builtin-0install solver

[kit-ty-kate]

Partially fixes #6824

This helps in cases where a needs to downgrade b and neither are required by anything else in the current switch.
If another package in the switch depends on a then anything can happen to b, sadly.

I'm guessing 0install-solver prioritizes the first dependency tree scanned (depth first) so ordering requested packages to emulate a priority system doesn't work in most cases because of that.

TODO:

• tests
• extract the extra_pkg names away from OpamCudf to avoid recursion in the build plan between OpamCudf and OpamBuiltin0install
• figure out a way to switch 0install from depth-first to breadth-first or "depth-first modulo first iteration"

[kit-ty-kate]

cc @talex5 in case my assumption isn't correct and if you know a simple way to make 0install-solver non depth-first to at least try it out

[talex5]

if you know a simple way to make 0install-solver non depth-first to at least try it out

The depth-first search is here:

https://github.com/0install/0install/blob/33275432c8579f519ae273b1921189aa3caec707/src/solver/solver_core.ml#L549

I don't recall any reason why it couldn't be breadth-first, but I haven't thought about it for a long time.

(possibly this code is a bit inefficient because it walks the tree every time it has to make a decision... but it's probably lucky I didn't optimise it as that would make changing it harder)

[kit-ty-kate]

Thanks a lot for the pointer. I was able to change the search to be breadth-first instead and it worked as expected!

kit-ty-kate/0install@3569d49

(the parent commit removes the part of the code dealing with commands since opam doesn't use it and it was easier to reason about and modify it that way)

This PR isn't exactly urgent or anything so we have time to figure this out but i'm wondering what's the best way to integrate that into 0install-solver. Maybe a setting value in S.SOLVER_INPUT which would choose depth-first or breadth-first depending on that value? Another alternative is to vendor it in opam-0install-cudf but it's probably best not to until we have more time to figure out what we would want to modify to improve the solver results.