fix: update resolve_all_features() to filter pkg deps

[Saplyn]

What does this PR try to resolve?

Before, resolve_all_features() isn't filtering dependencies, as it uses the set returned by Resolve::deps() directly which is mostly unfiltered. This PR fixes it by having the set goes through PackageSet::filter_deps()'s filter.

Note that this patch changed resolve_all_features()'s function signature as well as made PackageSet::filter_deps() public.

Close #15399

How to test and review this PR?

As described in #15399, cargo test --frozen should not panic (doesn't try to download unneeded deps) when does the following:

git clone https://github.com/hickory-dns/hickory-dns
cd hickory-dns
git checkout v0.25.1
mkdir .cargo_home
CARGO_HOME=.cargo_home cargo fetch --locked --target=x86_64-unknown-linux-gnu
CARGO_HOME=.cargo_home cargo test --frozen -p hickory-resolver

More discussion on Zulip chat.

[epage]

Not sure I'm in a good place to give feedback on the change itself at this time but wanted to highlight PR expectations (https://doc.crates.io/contrib/process/working-on-cargo.html#submitting-a-pull-request)

• A test will be needed for this
• It is really helpful if you create a test in its own commit that shows the panic and then put this commit on top that removes the panic. Then the diff between these two commits shows how behavior changed. This allows you to verify the test is testing the right thing and gives a good demonstration of the fix

[Saplyn]

Thanks! I'll look into how to write a test for this pr and try implementing it before making it ready for review

[rustbot]

r? @epage

rustbot has assigned @epage.
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

[ehuss]

Just some quick feedback on this test:

• Tests should not access the network or crates.io. Registries must be defined locally. See the calls to Package::new as examples.
• Tests should not hard-code target names. If possible try to model this without things that depend on the target (like maybe cfg(false)). See also the rustc_host() function if you need a target for cargo fetch.
• The first commit adding a test should show the failing behavior. That way we can see and verify what the change in behavior is in the second commit.
• Generally we don't create new modules to house a single test. Since this is essentially checking the behavior of dealing with features, I would probably just put it in the features module.
• For performance reasons, we tend to prefer using cargo check instead of other commands (--examples would be needed in this case).

[Saplyn]

1. I've changed to Package::new() and it now uses dumb-registery
2. It's now using rust_host() to detect host and the test ignores windows
3. I could confirm the test fails before the second commit and passes after, both privously and now
4. It's now moved into features (features::dont_demand_not_required_dep)
5. I've now changed to cargo check --examples

Sorry for force pushing into my own repo. I don't know how to keep all history there while keeping 2 commits (test, then fix) in order.

[Saplyn]

(I guess I should also @epage)