Tests are failing with "On Linux and MacOSX fsyncing a directory..." assertion error on pre-7.4 versions #46545
Description
Sometimes tests on CI fail with
10:53:20 2> java.lang.AssertionError: On Linux and MacOSX fsyncing a directory should not throw IOException, we just don't want to rely on that in production (undocumented). Got: java.nio.file.NoSuchFileException: /var/lib/jenkins/workspace/elastic+elasticsearch+7.3+matrix-java-periodic/ES_BUILD_JAVA/openjdk12/ES_RUNTIME_JAVA/openjdk13/nodes/general-purpose/x-pack/plugin/ccr/build/testrun/internalClusterTest/temp/org.elasticsearch.xpack.ccr.LocalIndexFollowingIT_C1509FBC009515F2-001/tempDir-002/data/nodes/0/indices/jGUuzRJWSUWeAuofKRr-jg/0/_state
10:53:20 2> at __randomizedtesting.SeedInfo.seed([C1509FBC009515F2]:0)
10:53:20 2> at org.apache.lucene.util.IOUtils.fsync(IOUtils.java:464)
10:53:20 2> at org.apache.lucene.store.FSDirectory.syncMetaData(FSDirectory.java:310)
10:53:20 2> at org.elasticsearch.gateway.MetaDataStateFormat.performStateDirectoriesFsync(MetaDataStateFormat.java:172)
10:53:20 2> at org.elasticsearch.gateway.MetaDataStateFormat.write(MetaDataStateFormat.java:246)
10:53:20 2> at org.elasticsearch.gateway.MetaDataStateFormat.writeAndCleanup(MetaDataStateFormat.java:185)
10:53:20 2> at org.elasticsearch.index.seqno.ReplicationTracker.persistRetentionLeases(ReplicationTracker.java:389)
10:53:20 2> at org.elasticsearch.index.shard.IndexShard.persistRetentionLeases(IndexShard.java:2100)
10:53:20 2> at org.elasticsearch.index.shard.StoreRecovery.writeEmptyRetentionLeasesFile(StoreRecovery.java:446)
10:53:20 2> at org.elasticsearch.index.shard.StoreRecovery.restore(StoreRecovery.java:490)
for example, see #45932 (comment).
This issue was addressed by @jasontedor here https://issues.apache.org/jira/browse/LUCENE-8843 (there is also similar PR to Elasticsearch codebase by @jasontedor #42972).
The thing is that the aforementioned Lucene patch is included starting with Lucene 8.2.0. All pre-7.4 Elasticsearch versions are using older versions of Lucene.
I'll close the issue as soon as it's created to simplify future test triages and know that we won't fix it.