Test cache trimming priority in the [copy] mode

[snowleopard]

I wanted to fix trimming in the copy mode because I thought it was broken, but when adding a test I realised that it actually works fine! I added a comment to explain how prioritising trimming by ctime happens to work both in hardlink and copy modes.

[snowleopard]

Strangely, the CI fails on Mac OS: for some reason, there our trimming heuristic works in the opposite order. If anyone has any ideas why this is happening, please let me know.

[ghost]

Could it be related to the FS times granularity on OSX? It's much more coarse than on Linux. We've had issues with this in the past and have special code to deal with this in cached_digest.ml.

[aalekseyev]

I don't know, but a wild guess is that perhaps ctime is not bumped on mac when you add or remove a hardlink.
(I don't really understand the test suite, just guessing from a blackbox perspective).

@jeremiedimino, I though that too, but I can see dune_cmd wait-for-fs-clock-to-advance pepperred around the test so I thought that idea was already explored.

[snowleopard]

Could it be related to the FS times granularity on OSX? It's much more coarse than on Linux.

@jeremiedimino Yes, that sounds plausible, which is why I used dune_cmd wait-for-fs-clock-to-advance after each ctime update. Perhaps, it's not enough.

I don't know, but a wild guess is that perhaps ctime is not bumped on mac when you add or remove a hardlink.

@aalekseyev The hardlink mode tests are fine. The problem happens only when testing the copy mode. So, perhaps, copying files on Mac OSX doesn't update the ctime as we expect.

[snowleopard]

@jeremiedimino I added an override for Mac OSX for problematic tests, as we discussed, so I think this is ready to be merged.

[ghost]

LGTM