Use new narrow requirement selection resolvelib api to reduce cost of resolution

[notatallshaw]

resolvelib 1.1 introduced a new API for providers: narrow_requirement_selection.

narrow_requirement_selection is very similar to get_preference but it is only called once per round whereas get_preference is called for the number of unsatisfied requirements there are in that round, which can be arbitrarily large.

In short narrow_requirement_selection allows the provider to narrow what requirements, by their identifiers, are considered for get_preference, reducing the cost of getting a preference, if it only returns 1 identifier then calling get_preference is skipped altogether.

Pip has two obvious preferences in it's current get_preference that can be moved to narrow_requirement_selection:

• REQUIRES_PYTHON_IDENTIFIER - Should always be considered immediately, this skips checking all other preferences if this identifier is present
• Backtrack Cause - Currently if there are a large number of unsatisfied names (n), and a large number backtrack causes (b) then getting a preference costs O(n*b), there have been reports that this can dominate the resolution time, by moving this to narrow_requirement_selection identifying backtrack causes costs O(n+b) and the cost is completely removed in getting the preference

[pfmoore]

LGTM. One typo in a variable name.

Note - I've only desk checked this, I don't have any useful examples of resolutions to test it against.

[notatallshaw]

Note - I've only desk checked this, I don't have any useful examples of resolutions to test it against.

Unfortunately the user who raised #10621 never provided a reproducible example, which was the initial report that led to making this API.

But, I will test this branch against all scenarios in Pip-Resolution-Scenarios-and-Benchmarks, which includes popular resolutions and known difficult resolutions, before merging.