Add cacheConfig, setter process, getter script

[bsofjan]

Per Phase 1.3 Setter Process and Phase 1.4 Getter Bootstrap of the Anycache Project Proposal, in this PR I am adding:

1. Setter process
2. Getter bootstrap
3. cacheconfig json

The goal of Phase 1.3 and Phase 1.4 is to put together the bare bones of a "setter" process and "getter" functionality.

[CJA18]

A few general things you need to do when committing to TorQ:

• The PR needs a more detailed description outlining the reason for it, what's being achieved, future steps to come etc
• A lot of these functions seem to be something common that has likely been done already and might have an existing util function, always check for this first as it's best practice to reuse the existing utils (if something needs to be changed then it only needs to be changed in one place)
• Follow coding standards, if you look at the rest of the codebase camelCase isn't used so follow whatever standard is used in the codebase
• For comments, in the rest of the codebase you'll see that the comments are generally block comments for each function describing what the function and each step in the function is doing, and inline comments are used in special cases (check the codebase to see when to use them)
• You committed an empty json config file, it's better to commit a file with some defaults so a reviewer can get an idea of what it will be used for

[bsofjan]

I have reviewed the TorQ codebase and could not find an existing utility function for the setter.q and getter.q functions. There are existing save and load utilities in the TorQ codebase, however they are highly specific (e.g. loading q and k scripts, saving partitions) and not suitable for use for saving and loading with the anymap data format.

I have also addressed all the other points through my latest commit "Standardising Changes and Add Default json" and by adding more detailed description to the PR.

[CJA18]

@bsofjan thanks for checking if the utility was present in TorQ and for addressing my other comments - looks good to merge

[bsofjan]

@CJA18 Thank you - I think it is best to wait prior to merging as the PRs functions as checkpoints of work, and merging can be considered once the whole project comes around.

[jonathonmcmurray]

filePath -> filepath

this also seems like a very thin wrapper around load, is it really useful to have this?

[bsofjan]

Hello Jonathon, I understand your comments, just to give you more context, I'm following the work development phases in the Anycache proposal which I found very useful as it gives me structure to the work progress to whole Anycache system. I hope you found this helpful!

[jonathonmcmurray]

filePath -> filepath

and similar to the getter function, very thin wrapper around set, is it useful?

[bsofjan]

Hello Jonathon, same as above, I understand your comments, just to give you more context, I'm following the work development phases in the Anycache proposal which I found very useful as it gives me structure to the work progress to whole Anycache system. I hope you found this helpful!

[jonathonmcmurray]

should this be a standalone process? seems like caching would be something that multiple processes would do so perhaps this should be a lib rather than a process?

[bsofjan]

The setter is a standalone process in the Anycache proposal so we can spin up many setter processes. Also the logic for the cachebuilder lives in the setter. The getter process is the lib where other processes can import to obtain the functionalities.