refactor: drop yanked_whitelist from source loading

[weihanglo]

What does this PR try to resolve?

Split off from #17012 for an easier review experience I guess.

Most call sites constructed with an empty allowlist,
and PackageRegistry::load was the only place that passed a real list
so we do a post construction after PackageRegistry in load.
The parameter was only load-bearing for PackageRegistry.

How to test and review this PR?

This has no user-facing behavior change.

[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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @ehuss, @epage, @weihanglo
• @ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
• Random selection from ehuss, epage

[epage]

On its own, this is likely fine and I would be fine reviewing and merging if you want but I wonder if we should go in a different direction for the motivating case behind this.

I worry about the complexity that has grown around yanked as we have added features around it, like --precise and that grows stronger in considering doing something similar for other features like min-publish-age.

One half-developed idea is that Source has no knowledge about yanked but passes up the enum of different types of summaries. VersionPreferences would then decide whether to filter out yanked items or not. One possible way of doing this is for anything in VersionPreferences that is preferred is implicitly blessed for yanked, min publish age, etc.

[weihanglo]

On its own, this is likely fine and I would be fine reviewing and merging if you want but I wonder if we should go in a different direction for the motivating case behind this.

While the original motivation of this PR wasn't about the larger refactor, removing whitelist from Source would always happen if we are going to move yanking behavior up to resolver. This refactor somehow minimizes future diff from touching too many files. Still worth merging I guess.