Base.stale_cachefile: allow ftime_req to be greater than ftime by up to one microsecond (to compensate for Windows tar)

[DilumAluthge]

This PR modifies the Base.stale_cachefile function, which is used in code loading to determine whether or not a .ji cachefile is fresh relative to its .jl source files.

In this PR, for each source file, we allow ftime_req (the original mtime of the source file as recorded in the header of the cachefile) to be greater than ftime (the current mtime of the source file), but only if ftime_req - ftime is strictly greater than zero and strictly less than one microsecond. In other words, we allow a cachefile to be considered fresh if the following condition is true: 0 < (ftime_req - ftime) < 1e-6.

Motivation

I am running into the following issue:

1. On GitHub Actions CI, trigger a new CI job on a GitHub-hosted Windows runner. This job runs inside a brand new virtual machine.
2. During the job, create a new depot, activate a new environment, add some packages, and precompile the environment.
3. At the end of the job, the "upload" step of the actions/cache action runs, which performs the following steps: tar up the depot, upload the tarball to GitHub's servers.
4. Trigger another CI job, again on a GitHub-hosted Windows runner. This job runs inside a brand new virtual machine that has identical specs to the previous virtual machine.
5. At the beginning of the job, the "download" step of the actions/cache action runs, which performs the following steps: download the tarball from GitHub's servers, extract the tarball to the exact same location as before.
6. Set ENV["JULIA_DEBUG"] = "all" and do import SomePackage.

Expected behavior: all of the cachefiles should be fresh.

Observed behavior: at least one of the cachefiles is stale. The @debug message shows that ftime != ftime_req. More specifically, ftime_req > ftime. However, in all of the tests that I have done, it has always been the case that 0 < (ftime_req - ftime) < 1e-6.

This makes it impossible to use the GitHub Actions CI cache to cache the Julia precompilation cache for Windows jobs.

Interestingly enough, I only see this issue on Windows. Everything works fine on the GitHub-hosted Linux runners.

[staticfloat]

The fix makes sense, but I don't understand the root cause; why is windows' tar fudging our timestamps?

[vtjnash]

More specially, how does it fudge it this oddly. Is it specifically rounding up (since we already handle rounding down)?

[DilumAluthge]

Yeah, I would really like to understand why this is happening.

As far as I can tell, all of the @debug messages look like this:

┌ Debug: Rejecting stale cache file C:\path\to\depot\.julia\compiled\v1.7\CSV\HHBkp_0PArC.ji (mtime 1.654090805352805e9) because file C:\path\to\depot\.julia\packages\CSV\0Elut\src\write.jl (mtime 1.654090805352804e9) has changed

It's always just that last digit that differs.