Discussion: Caching behaviour to avoid setting changes mid-plan

The base [client](https://github.com/DiamondLightSource/daq-config-server/blob/c500bddfb9d6fcca704ab5e276fb1c318169243f/src/daq_config_server/client.py#L31C7-L31C19) currently has a default expiry time for each entry, as well as a number of maximum items it can hold at once (I think this is first in first out).

If a Bluesky plan makes multiple requests using this client, and the second of these requests happens to be after the cache expiry time, or the cache fill up and drops the first entry, then the settings could change mid-plan without the user meaning to do this.

This seems like it could trip people up, but on the other hand, the default timeout if 1 hr - if we encourage people to make requests with `reset_cache=True` at the start of their plans, then this should be fine.

## Acceptance Criteria
- Decide if default cache behaviour is good
- Document that users should use `reset_cache=True` at the start of their plans, and guidance on their `cache_size` `cache_lifetime_s` values