And disable FileChannel.force() in the case of AtomicFileWriter.
See the committed javadoc for the full why.

(Note: mainly bumping for the CI to not fail since I was never able to
see this test fail on my machine [takes ~17 with this change] anyway
other than by running in Docker and aggressively reduce IOPS to 40 using
Docker resource constraints.)

Since we now *actually* sync to disk, this isn't really a regression IMO.
From the very role of AtomicFileWriter, it looks more like a feature or
an improvement than an issue.

So I suspect that anyway 1) we won't see
a lot of bad impact in the wild on most setups (as we generally already
recommend SSDs and so on as per how Jenkins works) and 2) we win anyway
in term of integrity by making sure (well, raising the chances, let's
say) we do write to disk before renaming files.

The goal here is to:
* be able to selectively choose performance over integrity in some very
  specific cases
* be able to globally disable AtomicFileWriter integrity, and basically
  revert to previous behaviour by setting a system property.
  This flag is meant as an emergency one in case something goes very
  wron on some production system.

As requested especially by Sam