init warning on stalled lock probe

init: If lock probing stalls for a long time (eg a broken NFS server),
display a message to let the user know what's taking so long.

doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_1_9c77d8cf628025308c2561a8a46d2365._comment

@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-06-05T14:43:13Z"
+ content="""
+So your nfs filesystem is making a posix lock operation block for 2 minutes
+before, I suppose, it makes it fail.
+
+Since git-annex has to do a posix lock operation, the only way to make it
+faster would be to fix the nfs filesystem to not do that. Perhaps by disabling
+posix locking altogether since it's apparently broken.
+
+But as far as what git-annex can do, I don't see any possible way to speed it up.
+
+I agree it could make sense to display a message, although that will also
+be a message the vast majority of users who are not in this situation would
+see. Maybe it could wait 1-10 seconds (probably 1000 times as long as it
+will take in most situations) and if the probe is still ongoing, display a
+message.
+"""]]

doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_2_0d7eb254ec9ff7ba8b1831898008747f._comment

@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-06-05T14:54:31Z"
+ content="""
+Also, it could check if annex.pidlock is already set globally, and skip the
+probe. Which maybe would work for you? 
+
+I'm going to implement both the delayed message, and checking
+annex.pidlock.
+
+(Timing out the probe after some period of time less than 2 minutes would
+also be a possibility, but then there could be false positives on
+filesystems that are just legitimately very slow. Doesn't seem a good
+idea.)
+"""]]