Fix: Caching thread safety

[screamerbg]

This aims to fix caching thread safety in Mbed CLI. It uses directory creation which is atomic operation on all operating systems. I've tested with the script @adamelhakham wrote. Additionally @adamelhakham tested it in their CI. I'd still advise to try it in staging CI rather than live.
Addresses #660

CC @teetak01 @yogpan01

[SeppoTakalo]

Concurrency issue here.
Other proces might have just opened the file, but not yet written to it.
On line 1385 it does:

                    with open(lock_file, 'wb', 0) as f:
                        info("Writing cache lock file %s for pid %s" % (lock_file, os.getpid()))
                        f.write(str(os.getpid()))
                        f.flush()
                        os.fsync(f)

So context switch might happen after open() but just before writing to a file.

This would lead to two processes thinking that they own the lock.

[screamerbg]

Then this would be handled by

                        if not pid:
                            if int(os.path.getmtime(lock_file)) + timeout < int(time.time()):
                                info("Cache lock file exists, but is empty. Cleaning up")
                                os.remove(lock_file)
                                os.rmdir(lock_dir)

This means if a lock folder exists and the file has been created and empty (just opened), there will be a 5 minutes time window during which all concurrent processes will be waiting for the file to be written with a valid pid value. This prevents the concurrency issue you described.

[screamerbg]

Will fix the Py3 issues. Please ignore for now.

[theotherjimmy]

I think that a context manager would improve the pythonishness and reduce the change of future programmer error.

[theotherjimmy]

Could this be safer as a context manager? That way we could never forget to unlock the cache.

[theotherjimmy]

We could also use the context manager here.

[teetak01]

cc: @adamelhakham

[theotherjimmy]

Addressed my own request.