GetWatchResponseTests failing when running jdk11

[pgomulka]

The test is passing when running under jdk8 but failing under jdk10 & 11
failing:

./gradlew :x-pack:plugin:core:unitTest -Dtests.seed=20A05DD93A2D55FA -Dtests.class=org.elasticsearch.protocol.xpack.watcher.GetWatchResponseTests -Dtests.method="testFromXContent" -Dtests.security.manager=true -Dtests.locale=ar-SA -Dtests.timezone=America/Kralendijk -Dcompiler.java=11 -Druntime.java=11

working

./gradlew :x-pack:plugin:core:unitTest -Dtests.seed=20A05DD93A2D55FA -Dtests.class=org.elasticsearch.protocol.xpack.watcher.GetWatchResponseTests -Dtests.method="testFromXContent" -Dtests.security.manager=true -Dtests.locale=ar-SA -Dtests.timezone=America/Kralendijk -Dcompiler.java=11 -Druntime.java=8

The resolution of SystemClock was changed from jdk8 - jdk11
The jdk is vauge about this:

This clock is based on the best available system clock. This may use System.currentTimeMillis(), or a higher resolution clock if one is available.

JDK8 SystemClock from Clock.java

  @Override
        public Instant instant() {
            return Instant.ofEpochMilli(millis());
        }

jdk11 SystemClock.instant from Clock.java

 @Override
        public Instant instant() {
            // Take a local copy of offset. offset can be updated concurrently
            // by other threads (even if we haven't made it volatile) so we will
            // work with a local copy.
            long localOffset = offset;
            long adjustment = VM.getNanoTimeAdjustment(localOffset);

            if (adjustment == -1) {
                // -1 is a sentinel value returned by VM.getNanoTimeAdjustment
                // when the offset it is given is too far off the current UTC
                // time. In principle, this should not happen unless the
                // JVM has run for more than ~136 years (not likely) or
                // someone is fiddling with the system time, or the offset is
                // by chance at 1ns in the future (very unlikely).
                // We can easily recover from all these conditions by bringing
                // back the offset in range and retry.

                // bring back the offset in range. We use -1024 to make
                // it more unlikely to hit the 1ns in the future condition.
                localOffset = System.currentTimeMillis()/1000 - 1024;

                // retry
                adjustment = VM.getNanoTimeAdjustment(localOffset);

                if (adjustment == -1) {
                    // Should not happen: we just recomputed a new offset.
                    // It should have fixed the issue.
                    throw new InternalError("Offset " + localOffset + " is not in range");
                } else {
                    // OK - recovery succeeded. Update the offset for the
                    // next call...
                    offset = localOffset;
                }
            }
            return Instant.ofEpochSecond(localOffset, adjustment);
        }

[elasticmachine]

Pinging @elastic/es-core-features

[pgomulka]

very similar problem to what I did here..
d821da0

[javanna]

can we mute this test if we are not going to merge the corresponding PR straight-away?