[SYNPY-1316] Updating to caching logic to take in MD5 key

[BryanFauble]

Problem:
In the .cacheMap file there is a key-value pair of path to file for a particular file handle ID and it's associated modified time, for example:
{"/home/bfauble/synapseTestFiles/bryansTestProject/temp/file_1.txt": "2023-11-03T21:46:48.000Z"}

In cases where we are downloading files into the same directory and a file with the same name is matching the current cache mechanism can incorrectly assume the file is already present in the directory and not attempt to download a new copy with ifcollision='overwrite.local

Solution:

• When we are adding new items to the cache store the file MD5 at the time of caching too. When we are checking for a cache hit verify if the local file has a different modification time and (if present) that the md5's match. If neither pass treat this as a cache miss.
• The way this is written will allow for backwards compatibility if a cache entry only has a timestamp - it will continue to remain in the timestamp format until there is a cache miss.

Testing:

• All passing integration and unit tests
• I also verified the before/after functionality of my .cacheMap when the new key is and is not present and the expected cache hit/miss occurs
• I also verified changing the MD5 value in the .cacheMap correct sees it as a cache miss
• I also verified that changing the file prompts a cache miss

[pep8speaks]

Hello @BryanFauble! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

• In the file synapseclient/core/cache.py:

Line 364:89: E501 line too long (95 > 88 characters)

• In the file tests/unit/synapseclient/core/unit_test_Cache.py:

Line 561:89: E501 line too long (92 > 88 characters)
Line 582:5: F811 redefinition of unused 'test_cache_item_unmodified_modified_items_is_modified_timestamp' from line 552

Comment last updated at 2023-11-03 23:54:15 UTC

[thomasyu888]

💯 I'll take a more in depth look later, but the test cases and the code make sense. I had forgotten about the how we leverage the cachemap even when using those other parameters. Thanks @brucehoff for the catch!

We will only write to the cachemap if there is a cache miss correct?

[brucehoff]

We will only write to the cachemap if there is a cache miss correct?

Yes: The cachemap records the state at the time of a file download (capturing the local time stamp). So writing only occurs when a file is downloaded (when there is a "cache miss".