chore: use parking_lot instead of std::sync for locks

[dsherret]

We're already using parking_lot extensively, but transitvely in dependencies. For example, parking_lot is used by tokio instead of std::sync for locks as a performance optimization. It might be good for us to also use it as it uses less memory, is faster, and has more features (I've used it in my projects and the API is a bit better).

Relates to #3429.

From https://crates.io/crates/parking_lot

When tested on x86_64 Linux, parking_lot::Mutex was found to be 1.5x faster than std::sync::Mutex when uncontended, and up to 5x faster when contended from multiple threads. The numbers for RwLock vary depending on the number of reader and writer threads, but are almost always faster than the standard library RwLock, and even up to 50x faster in some cases.

[bartlomieju]

If benchmarks are favorable then LGTM.

[dsherret]

@bartlomieju benchmarks look basically the same. I don't think this change affects much in the benchmarks as there aren't any of these locks used in any hot paths that I can see, though it would be nicer to use.

This PR is more a "might be nice to have"

[ry]

I’m skeptical about using non-std functionality for performance reasons, when the benefit hasn’t been demonstrated.

I’m not necessarily against it but deferring to @piscisaureus for review.

[dsherret]

Makes sense. I suspect if we turned off the parking_lot feature in tokio we would notice a difference, but yeah after running the benchmarks I see no performance benefit of this PR. The API is better and this PR makes us use parking_lot more consistently though. Perhaps some future code might benefit from it being faster. I don't have strong feelings though.