Replace tokio mutex with std mutex

[CodeMan62]

Motivation

1. Performance: std::sync::Mutex is generally more efficient when the critical sections are short and contention is low, as it avoids the overhead of async machinery.
2. Simplicity: Standard mutex provides a simpler implementation that's more straightforward to reason about.
3. Best Practices: As noted in the Tokio documentation, it's recommended to use std::sync::Mutex when:
   • The critical sections are short
   • The mutex isn't held across .await points
   • Performance is a priority

Fixes #1062

Solution

The solution involves:

1. Replacing instances of tokio::sync::Mutex with std::sync::Mutex throughout the codebase
2. Updating the corresponding lock/unlock patterns to use the standard library implementation
3. Ensuring that no mutex is held across .await points to maintain correct async behavior
4. Verifying that all critical sections are short-lived to maximize performance benefits

Thanks for reviewing it let me know if any changes required

[tasn]

This seems wrong? Won't be block the async thread every time we wait on a lock?

Also the unwrap feels like a code smell.

[svix-jplatte]

Yeah, the sender is by necessity held over await points so we must not use a std Mutex for it.

[tasn]

https://github.com/svix/svix-webhooks/pull/1866/files#r2029365945

[svix-jplatte]

All of the changes outside of the test code still look wrong to me. I'm pretty sure we need the async mutex in all of those cases. And for the test code, it doesn't seem all that useful to switch either.

I will trigger CI to run again to make sure, but unless you have a specific reason to believe there is a worthwhile change here, I'd encourage you to close this PR and I'll close the associated issue since it doesn't look like there was anything of substance there really.

[CodeMan62]

associated

Hii @svix-jplatte thanks for review i am closing this PR. please close the associated issue too.