Avoid two hot String allocations in deserialization

[woodruffw]

Summary

Was reading this code while looking at adding PEP 792 support and noticed these: by using the borrowing deserializer instead of the owning one, we can probably save a good number of small-ish String allocations in the PypiFile and PyxFile deserializers.

(These deserializers in turn are probably pretty hot, since large installations/resolutions require pulling lots of candidates from indices.)

Test Plan

No functional change expected; I'm not sure what the best way to microbenchmark this is. I'll try and contrive something locally.

[woodruffw]

Note: I realized after-the-fact that this could be subtly incorrect. For example, sometimes serde can't borrow a string because it needs to de-escape it from its JSON or other serialized form.

In practice that's probably fine in this context, since we don't really expect any weird escaping to happen on these key names. But it means that we can't just go around swapping <String> for <&str> with full generality.

Ref: serde-rs/serde#1413

Ref: https://users.rust-lang.org/t/solved-serde-deserialize-str-containig-special-chars/27218

[konstin]

Can we use Cow<str, _> here, which is both correct and doesn't allocate in the regular case?

[woodruffw]

Can we use Cow<str, _> here, which is both correct and doesn't allocate in the regular case?

Yeah, that would be the most correct/general solution! I think we could probably do the same for every callsite of String::deserialize as well, although some of those may not meaningfully benefit from saving a copy if we need an owned String anyways.

For example, impl<'a> serde::Deserialize<'a> for PythonRequest can probably be cow'd.