Consider using `std::sync` instead of parking_lot

[matklad]

paperclip today uses parking_lot. parking_lot provides faster, smaller mutexes, at the cost of adding a somewhat churn-prone dependency. It's not uncommon for downstream projects to end up with a couple of different versions of parking_lot in the Cargo.lock.

Naively, I would assume that mutext perfomance should not matter for the thing that paperclip is doing, and that sticking with std mutexes would make more sense, especially in the light of rust-lang/rust#95035.

[tiagolobocastro]

I believe you are right, mutex performance should not be critical here.
One snag might be the usage of parking_lot mutex on the autogenerated client code via CLI, as that is a public api.

As an aside, it's interesting how it's being used there. At a first glance, not sure why we need the response wrapped in a mutex.

    pub enum ApiError<R: Debug + Send + 'static> {
        #[error("API request failed for path: {} (code: {})", _0, _1)]
        Failure(String, http::status::StatusCode, Mutex<R>),
        #[error("Unsupported media type in response: {}", _0)]
        UnsupportedMediaType(String, Mutex<R>),
        #[error("An error has occurred while performing the API request: {}", _0)]
        Reqwest(reqwest::Error),.......
    }

[matklad]

One snag might be the usage of parking_lot mutex on the autogenerated client code via CLI, as that is a public api.

Note that as pl released a new major version, you'd have to break that anyway to upgrade pl. So, in principle that's another argument for switching to std.

But yeah, that's going to be a semver-breaking change either way, and yeah, it might make sense to maybe remove mutexes from public API altogether. That ApiError looks like something very prone to breakage.