Refactor -r pylock.toml, support release control and dependency cooldown

[sbidoul]

Instead of adding a locked_link and locked_version to InstallRequirement, provide a locked link per project name to the PackageFinder.

Let get_all_candidates ignore indexes and --find-link when a locked link is known for a project.

This naturally supports format control, so the duplicate implementation in constructors.py can be removed. This also naturally addresses release control, as well as --uploaded-prior-to (via the upload_time field of pylock.toml). Revert the change that I had made to resolvelib/factory.py, which was a bit awkward.

All in all, this is a much simpler and natural implementation, I think.

TODO:

• check if this approach helps with
  • Improve the conflict report when a package from pylock.toml conflicts with other requirements #13963
  • improving format control error reporting
• add a test for --uploaded-prior-to
• better error message for duplicate pylock entries for the same project

closes #13950
closes #13963
closes #14168

PR Checklist:

• I agree to follow the PSF Code of Conduct.
• I have read and have followed the CONTRIBUTING.md file.
• I have added a news file fragment (or this PR does not need one).
• I have read and followed the AI_POLICY.md file, and if any AI tools were used, I have disclosed it below.

[sbidoul]

This is ready. I think it makes a lot of sense to involve the PackageFinder to provide the locked links, because a lock file can been seen both as a source of requirements, and as a sort of index page which provides the available versions and artifacts URLs.

[ichard26]

I need to do a second pass on this, but I agree this is a much cleaner approach. Kudos!

I have two general notes:

• This seems to regress support for falling back to a sdist over a wheel when the latter is rejected by --no-binary? I guess that's what the TODO is for. Since this needs a packaging change, it seems unlikely that this will be fixed in time for pip 26.2. Speaking as the RM, I'm fine with that since this use-case seems quite rare and pylock support is still experimental, but I do want to flag this explicitly.
• It's a bit unfortunate that some of the new errors don't include which lockfile the locked link comes from. This isn't a showstopper since using multiple lockfiles is likely similarly uncommon, but it could be a source of confusion nonetheless.

I still have opinions on the overall direction and shape of our pylock installation support, but I'll save that for the issue threads (and later because I haven't thought about in a while).

[sbidoul]

Thanks for the review and typo-catching.

This seems to regress support for falling back to a sdist over a wheel when the latter is rejected by --no-binary

It's not a regression, rather something I noticed recently and added a TODO for it.

It's a bit unfortunate that some of the new errors don't include which lockfile the locked link comes from

Same opinion here. This is probably fixable but I don't want to spend time on this right now given the unlikeliness of these errors.

Regarding opinions, looking forward to reading them :) I'm aiming at a consistent UX for "lock files as just another requirements source" and I feel it fits well so far, both from a UX and architecture perspective. I believe this makes sense for the low level pip commands we have. This does not preclude the creation of higher level commands such as pip sync.