moss: sync behaves weirdly and needs fixing

[ermo]

The current moss sync orphan handling is funky. Fix that.

Ikey Doherty so the current orphan solve premise is ignoring a few vital facts and is basically trying to shortcircuit the need for graph logic ie being too smart for its own good as we know graph manipulation requires recursion so we're currently doomed to first-level nodes the only realistic solve i see for this is (in parallel) compute the rdep (transposed subgraph of current set) chain for each transient marked dep in the selections then sort by their chain length and try to apply, discarding any that result in a .Explicit selection being removed (such that we try from shortest chain first and implicitly merge same groups by nature of left-to-right) returning a set of "safe to remove" ermo this sounds suspiciously like the issues the debian apt 3.0 solver is running into. (which is neither a good nor a bad thing per se; just the nature of the beast) Ikey Doherty yeah but this is also the solution i proposed when we first looked at the sync stuff and then we took the easier option which, yknow, bullet meet ass. ermo well, otoh, now we know the easier solution is not good enough (...) Ikey Doherty TL;DR: tarkah our orphan occlusion is a bit "wrong" we also dont occlude the installed candidates when a sync would take pkg from A to B version, to exclude the A version providers as it bricks deps in non sync'd transients tarkah Ye that makes sense Ikey Doherty+1] My local work is basically adding a btreeset to a transaction that we can preload it with the known package::Id to occlude and then filter in our lookup function tarkah We should explicitly remove all transitive deps of A when A -> B before we do the next pass Ikey Doherty such that we restrict our registry access to not see "gone" guys well we should probably fix our wording to avoid confusion here we need to strip first-level dependencies when janking a package Id out of the potential selections as "remove" to me entails the whole dag dance