Update file metadata cache if folder name changes

[JobLeonard]

Title says it all.

Steps to reproduce:

• open the loom viewer, which causes the file metadata to be generated and cached
• rename the project folder
• refresh main page
  • [optional] open loom file, which will not open because it is an invalid path

Expected:

• project name updates on refresh of page

What happens instead:

• old project name remains because it is stored in FILENAME.loom.file_md.json.gzip as part of project attribute. Example:

{
  "project": "Buggy",
  "filename": "Hindbrain_neurons.loom",
  "dataset": "Hindbrain_neurons.loom",
  "title": "Hindbrain_neurons.loom",
  "description": "",
  "url": "",
  "doi": "",
  "creationDate": "2018/03/06 17:04:06",
  "lastModified": "2018/03/06 17:04:06",
  "totalCells": 1944,
  "totalGenes": 27998
}

Note that there is also a potential bug with loom file renaming - currently this is not an issue, because the server detects the loom file first, then searches for matching cached metadata. However, depending on this behaviour seems like a bad idea, in case we change caching strategies later, and it is a very simple check to perform.

Fixes

• [x] when loading FILENAME.loom.file_md.json.gzip:
  • [x] check if current project path still matches the saved project path
  • [x] check if current filename still matches the saved filename
  • [x] replace cache in case of mismatches

Other thoughts

When iterating over a project folder, it might be prudent to delete any extracted metadata without a matching loom file.

• ✔️ pro: automatically cleans up stale cache
• ✔️ pro: avoids issue of renaming a loom file, later replacing it with another loom file, and the new loom file being stuck with old stale cache
• ❌ con: does not prevent previous when immediately replacing a loom file.
  • ✔️ Counterargument: this is the kind of "expert mode" renaming where one should realise the cache needs to be updated.
    • Add to documentation?
• ❌ con: when debugging, I sometimes rename metadata to a backup, then change code, then refresh to see if changes in code reflect changes to cache.
  • ✔️ Counterargument: specific niche debugging scenario,
  • ✔️ Counterargument: different renaming scheme (FILENAME.loom.old_file_md_1.json.gzip instead of FILENAME_old1.loom.file_md.json.gzip) fixes this.
  • ✔️ Counterargument: as an alternate workaround, not auto-cleaning in debug mode will avoid this issue (and is likely useful for debugging anyway)

Verdict: should be implemented (also for other cached metadata), but this feature is a separate, low-priority issue.