Add cache warmup strategy for OCS resource infos

[ishank011]

Recently, a TTL cache was added to OCS to store statted resource infos #1643. This PR adds an interface to define warmup strategies and also adds a cbox specific strategy which starts a goroutine to initialize the cache with all the valid shares present in the system.

@refs @butonic @labkode please take a look at this when you get the time. I'm not 100% sure about the design so would love any feedback. I'm also thinking about adding a strategy with the json share + OCIS drivers.

[butonic]

I don't feel fit for an in depth review today, but my mind immediately wandered towards caching the root etag for a storage space in the storage registry instead of the ocs or ocdav services. In any case, I think it makes sense to add a cache to the ocs service.

In my head a received share is also represented by a storage space. AFAICT the gateway and the storage providers have the ListStoragSpace API, which needs to still be implemented. So I am in favor of caching the results of the StorageSpace lists instead of adding a cach for stat results ... althoug one could argue that a storage space and a stat actually are the same thing.

I am trying to clarify the terminology. Maybe tomorrow a PR will be ready to clarify the terms ... just not feeling well ...

[refs]

LGTM, just a nitpick