[DEV] merge or simplify storage interfaces

[rainest]

Short Description
Either merge the DistributedLockProvider interface functions into the StorageProvider interface or remove duplicate functions from `DistributedLockProvider).

Definition of Done
Either:

1. StorageProvider has the GetDuration(), DistributedTimedLock(), and Unlock() functions currently in DistributedLockProvider. The DistributedLockProvider interface has been removed and functions that accept it now use StorageProvider instead.
2. DistributedLockProvider no longer includes Init(), InitFromStorage(), or Ping() functions.

My preference is to merge the interfaces.

Additional context
AFAICT DistributedLockProvider has no reason to be separate. There are no StorageProvider implementations that are not also DistributedLockProvider implementations, and I do not expect we will ever have reason to implement a StorageProvider only in the future.

At present their separation leads to unnecessary duplication of Init() and Ping() code and the weird InitFromStorage() partial copy via prayer and abuse of interface{} method.

If the interfaces remain separate, we'll need to remove some calls to Ping() that are superfluous (the functions also ping the storage engine already).

If we expect implementations that do not implement distributed locks (for a either single PCS instance or PCS instance groups with only one leader), we can make the distributed lock functions no-ops in those implementations.

On further review, we have no need for GetDuration(); it should be removed regardless. It's only used in its own test, and provides no functionality other than echoing an ephemeral function parameter(a lock grab timeout).

[rainest]

For background, the distributed lock is currently only used for determining the power status master. This determines whether the PCS instance will update the list of HW components and their current power status in the background. There is only one master instance at a time; all other instances only read the component list and observed state.

AFAIK all other PCS functions (handling API requests and issuing power state change requests) can be handled by any instance.

In Kubernetes, https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#LeaderElectionRunnable could handle this using separate runnables in a replica set with leader election enabled. The state tracker runnable would require leader election, the others would not.

I'm halfway inclined to separate the state tracker into its own service so that the rest of PCS can run without worrying about leader election. That separate service would have a controller-runtime leadership implementation available for Kubernetes, but would leave management up to admins for other platforms (you'd either run a single replica only or provide your own out-of-band active/passive system).

Without BSS (which probably didn't really need it), PCS is the only service that uses leadership election in CSM. Nothing else uses the distributed locks in hmetcd and nothing else calls the upstream etcd NewMutex().