Implement caching on get_configuration

[olliesilvester]

To make this config-server more responsive, we should implement caching

First requires #65

Acceptance Criteria

• When get_configuration is run with a filepath which it hasn't seen before, it reads the filesystem and caches the json. The cache will then be used when get_configuration is used with the same filepath
• Add an optional refresh parameter to get_configuration. When true, it will read from the filesystem and update the cache. It will be the responsibility of a Bluesky plan to refresh parameters when appropriate.
• Document how a Bluesky plan should refresh a parameter

[DiamondJoseph]

Should the caching mechanism just check if the file is dirty?

[olliesilvester]

Should the caching mechanism just check if the file is dirty?

I was planning on it storing the json output until told to refresh. @DominicOram is concerned about speed. Given all of the filesystem issues I think that's sensible

[DiamondJoseph]

Can't the client that is requesting the data cache the value until it thinks it needs to refresh (which would be the times that the config server is "told to refresh"), and the config server cache until it has some reason to think the file on disk has changed?

Else every call to the config server requires a check in the client to see if this is the first time that client has called the config server: if it is, it must force refresh as it doesn't know the age of the cached value (could have recovered from an issue that happened just prior to normal refresh).

This also means that the caching behaviour can be per-client.

Eventually client gets a time-to-live cache if it's happy to use a slightly outdated value and the config server has a cache keyed to the hash of the file which changes when the contents change

[DominicOram]

Yh, I'm happy to cache client side

[olliesilvester]

Me too. This should be easy enough to add in https://github.com/DiamondLightSource/daq-config-server/blob/main/src/daq_config_server/client.py

[olliesilvester]

@Relm-Arrowny I think the lru_cache decorator would be good here

[DiamondJoseph]

I'm pretty sure you want cachetools.TTLCache instead

    @lru_cache(5)
    def _get(
        self,
        endpoint: str,
        item: str | None = None,
    ):
        r = requests.get(self._url + endpoint + (f"/{item}" if item else ""))
        return r.json()

Would calculate the hash of (endpoint, item), and use that as a key to the return of r.json()- when it receives the 6th unique hash, it would discard the key that hasn't been called in the longest time. This means that if you're often making the same call, it will never be cleared out. @lru_cache or @cache (when you only expect a single key) are useful if you're calculating something deterministic, but not quite right if you're fetching something that may update

[olliesilvester]

Yep a time-based cache makes more sense.

We should also give the client a clear_cache function.