Cache calculated hashes for requirements and _InstallRequirementBackedCandidate

[notatallshaw]

This builds on @sbidoul PR #12453.

I was profiling the scenario here #12314 (comment), and found over 30% of the time is spent calculating the hash of specifier requirements, which is mostly spent calculating the string of the install requirement, and is done repeatedly.

After this PR installing all the homeassistant wheels from local directory went from ~48 seconds to ~35 seconds, and dry-run install of apache-airflow[all] with all packages cached on Python 3.12 went from ~4 minutes to ~3 minutes.

[notatallshaw]

Even running the very simple pip install requests --dry-run --ignore-installed I see about a 1-1.5% performance improvement over several dozen runs.

[pfmoore]

Why not hash on demand? Initialise _hash to None, and calculate the first time through __hash__. It's probably marginal, but it seems like more common practice.

Also, this assumes the fields that are used to compute the hash never change. Do we have anything to ensure that's the case? I'm sure it is, but it would be a little annoying if some clever hack in the future violated that invariant and we didn't catch it.

[notatallshaw]

Why not hash on demand? Initialise _hash to None, and calculate the first time through __hash__. It's probably marginal, but it seems like more common practice.

I can do that, but be aware it will almost certainly be a little slower, in the scenario of a large number of packages the __hash__ function is being called hundreds of thousands of times (because this is being called by resolvelib in an O(n^2) algorithm), so even a if self._hash is not None: return self._hash is going to add a little bit of time.

And I don't think there's a scenario where the hashes aren't being used, maybe in the case of --no-deps?

Also, this assumes the fields that are used to compute the hash never change. Do we have anything to ensure that's the case?

Only that the hash is dependent on internally marked attributes of internally marked apis, nothing in pip's codebase is changing them. Of course if someone is calling pip as a library and using the internal api and changing the internally marked attributed this will break, but I think lots of other assumptions will break if these attributes are changed, including, I think, the way #12453 was implemented.

[notatallshaw]

so even a if self._hash is not None: return self._hash is going to add a little bit of time.

I performance tested this to see if this assumption held up in the face of real data, and found in general the performance difference was within the margin of error. So I've switched to @pfmoore's suggestion of lazily calculating hashes and caching their results.

[notatallshaw]

Fixed MyPy errors, cleaned comments, rebased