This pulls in #3790, which provides retries in more of the POSIX emulation functions to be more resilient in the face of files locked by the aggressive locking semantics in Win32, and #4073, which allows consumers to configure their own locking strategies so that consumers can "get out of the way" of their users a bit more instead of locking files unnecessarily.

I refactored these a bit: this now introduces a do_with_retries macro that will execute the given function up to 10 times, retrying if the error appears to be something like a locked file. Callers can provide a "cleanup" function - perhaps to set the file writable - that will be called between invocations of the main function. This allowed us to clean up some patterns of try / set writable / try again.

I introduced the GIT_RETRY constant here. This is internal only and should never be returned to callers.

These new retryable functions call the win32 functions directly instead of calling Windows' POSIX emulation functions, which allows us to use the win32 error codes which are more fine-grained. This allows us to retry only particular failures (ie, ERROR_SHARING_VIOLATION ) instead of a sharing violation and all the other failures that get mapped to a particular POSIX errno.

This also allows us to bring in the configurable share mode for CreateFile, in #4073.

Once p_utimes called a retryable version of p_open, I noticed quickly that it was retrying all the time. Our ODB freshening test was freshening an object in a repository that had been copied over from a test harness and - as a result - the objects were all writable. Thus p_utimes would succeed on Windows. But freshening a file that we wrote - and thus marked as read-only - would fail. Oops. So I made p_utimes deal with read-only files by setting them writable temporarily to update the time.