test: add support for features in the sat resolver

[x-hgg-x]

What does this PR try to resolve?

This PR implements the first step of #11938 (comment).

How should we test and review this PR?

The first commit does some refactorings, and the second commit updates the SAT resolver.

List of boolean variables in the SAT resolver:

• One variable representing the activation of each registry package.
• One variable representing the activation of each feature of a given registry package.
• In the sat_resolve() method, we create an additional representing the activation of the root package.

List of clauses in the SAT resolver:

• If a package feature is activated, then the package should be activated.
• No two packages with the same links set.
• No two semver compatible versions of the same package.
• For each package:
  • For each feature:
    • If the package feature is activated and it depends of another feature of the same package, then it is also activated.
    • If the package feature is activated and it depends of a dependency, then at least one of the compatible dependency package should be activated.
    • If the package feature is activated and it depends of a feature of a dependency, then the feature of a compatible dependency package should be activated only if the compatible dependency package is activated. If this is not a weak dependency feature, then at least one of the compatible dependency package should be activated.
  • For each dependency, if the package is activated and if the dependency is non-optional or has been activated, then at least one of the compatible dependency package and its required features should be activated.
• The root package has the same dependency clauses but has no features.

List of assumptions in the SAT resolver:

• The root package is activated.
• Old root packages from previous calls to sat_resolve() are deactivated. This is necessary since the proptest call sat_resolve() several times with a different root package using the same SAT resolver, and clauses relative to the root package are not removable.

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Eh2406]

Thank you so much for working on this! I look forward to digging into what you've done.

That being said, there's a lot here. Any advice for where to start? Is it possible to split up the change into smaller logically separable commits? For example changing resolve to take a Summary instead of a list of deps, could probably be its own commit that happens before the code that actually looks for the feature table. That might make it easier to review what is "just" mechanically moving the arguments around, and what is fundamental changes. And would be a good place for me to ask "would it be clearer if we leave resolve with the same simple API for the tests that exist and add a resolve_with_features for things that use the new functionality?".

[x-hgg-x]

I splitted the PR in two commits and updated the PR description.

[Eh2406]

In reviewing this I'm noticing how very long lib.rs and resolve.rs are getting. Let's not do it in this PR, but as a follow-up it would be really nice to split these monoliths into separate files.

[ehuss]

r? Eh2406

[Eh2406]

I'm down to some nits at this point. Thank you so much for all the work.

[Eh2406]

Thanks for the work!
@bors r+

[bors]

📌 Commit 6f1315b has been approved by Eh2406

It is now in the queue for this repository.

[bors]

⌛ Testing commit 6f1315b with merge 2d368ed...

[bors]

☀️ Test successful - checks-actions
Approved by: Eh2406
Pushing 2d368ed to master...