refactor: handle cache mutex in common

[mkykadir]

Description

Mutex lock for cache can be handled from a common place instead of the on the method usage.

[jelias2]

Thanks for the contribution!

StaticRPCHandler currently handles an cache interface, which can either be in-memory, redis cache, or something else in the future.

Its a good idea however my concern is by moving the rw.Mutex from the StaticRPCHandler to the cache.go, the StaticRPCHandler will now depend on private implementations to avoid locking errors if the cache implementation is extended to something else in the future.

[mkykadir]

yeah exactly, that was my point actually for this change. I think the caching mechanism should be responsible for concurrent access and lock mechanism. What if that new caching method may require some other way to avoid locking errors, or another caching library is to be integrated that already capable to handle concurrent access. And cache.go can be utilized somewhere else in proxyd and locks should already be handled.