git_cache: give 20 secs timeout to lockfile.Lock() in contains_revision

https://crrev.com/c/6507483 changed contains_revision() to acquire
the cache lock before checking the existence of the sentinel file
to avoid race conditions.

After the CL, git_cache.py acquires the lock in the following places.
1. sync()
2. contains_revision()

It's reasonable to raise LockError() while there is an ongoing
sync(). However, the timeout can cause unexpected LockError()
if multiple processes are calling contains_revision() at the same time.

This CL simply gives it 20 secs, meaning that it would retry acquiring
the lock every 0.1s until it reaches 20 secs. A better approach is
using a read-write lock.

Bug: 421234614
Change-Id: I295652a2ef20a5b1f732908a522548c43c05d934
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/6621430
Commit-Queue: Scott Lee <ddoman@chromium.org>
Reviewed-by: Gavin Mak <gavinmak@google.com>

git_cache.py

@@ -317,8 +317,18 @@ class Mirror(object):
         if not self.exists():
             return False
 
-        # If the cache population is in progress, this will raise LockError().
-        with lockfile.lock(self.mirror_path, timeout=0):
+        # This will raise LockError(), if another process is
+        # 1) sync()-ing or
+        # 2) calling contains_revision().
+        #
+        # In case (1), the caller is responsible for handling the LockError().
+        # As per (2), the below gives 20 secs timeout just to cover most
+        # practical cases.
+        #
+        # Ideally, read-write locks should be used, Then, the below would
+        # - acquire the read lock immediately or
+        # - raise LockError() if there is an ongoing sync()-ing.
+        with lockfile.lock(self.mirror_path, timeout=20):
             # If the sentinent file exists at this point, it indicates that
             # the bootstrapping process was interrupted, leaving the cache
             # entries in a bad state.