Add support for File cache store

[ElijahAhianyo]

Now that we have the cache machinery set up, we should add support for a file cache store as well

[achsanalfitra]

Hi @m4tx, if this issue is still open, I'd like to take a crack at it. I've been researching fs for caching for a few days, and its tracked on this repo: https://github.com/achsanalfitra/smg_rsfc.

My proposal for this feature would be:

1. Use persistent fs using cacache (although, I'm open to any backend or pure std::fs approach if cacache is too heavy).
2. Implement in memory registry to bridge between the business logic (insert, get, delete, contain_key ... ) with the hash based content addressing.
3. Implement a resync on new() for rehydration on server restart (might default to clear state if this is seen as too complex).

If this sounds good, I'll work on it then make a PR when ready. I'd love to adjust if there are specific needs from this project

[ElijahAhianyo]

Hey @achsanalfitra, thanks for your interest in this. For this issue, I think this should be structured similarly to the Redis cache store or take inspiration from the file-based session store. Ideally, we want users to be able to provide a location to store the cache data/files (we should set this as a config knob just like we do for the file-based session store).

When storing/setting a value in the cache, the file name is essentially the key, and its content is the value. It would be great to hash the key(using MD5) before storing it to have a fixed length and prevent other length-bound or safety issues.

If this is still not clear, feel free to ask any questions, and we'd be happy to provide any clarity

[achsanalfitra]

Hi @ElijahAhianyo, thanks for the feedback! I've looked into the patterns from redis cache and file session implementations and I think I've got the overall idea. I'll get started on it.

I'll ask further questions if there are specific issues that come up along the way.

[achsanalfitra]

Hi team, I have implemented the main features File Store Impl, but I'd like to confirm some considerations. Currently, the file session embed the TTL into the json data itself. My concern was, if the file-backed cache also does the same, it would over-allocate when reading expired data, which is fine for smaller data but maybe not for bigger blobs.

My current implementation takes inspiration from Django's implementation, where they would dump the expiry on the first few bytes of the file and reading only the same part when checking expiry.

If there are other alternatives, I'll be open to adjust the implementation

[seqre]

@achsanalfitra can you please create a PR with your changes? This will be the easiest way for us to comment on your work and give any advice. Thank you for you effort!