Using actual time instead of cached time to avoid the snapshot time a…

…nd policy action time being identical in tests (#75983)

In TimeSeriesLifecycleActionsIT.testWaitForSnapshotSlmExecutedBefore() we create a snapshot, then associate an ILM policy with an index, and then that policy checks if a snapshot has been started at the same millisecond or later than the policy's action's date. Since both the snapshot start time and policy are using ThreadPool.absoluteTimeInMillis(), it is possible that they get the same cached result back (it is kept for about 200 ms). This change configures ThreadPool.absoluteTimeInMillis() to always use System.currentTimeMillis() rather than a cached time. So the policy's action date is always after the snapshot's start.

x-pack/plugin/ilm/qa/multi-node/build.gradle

@@ -28,6 +28,14 @@ testClusters.all {
   setting 'indices.lifecycle.poll_interval', '1000ms'
   setting 'logger.org.elasticsearch.xpack.core.ilm', 'TRACE'
   setting 'logger.org.elasticsearch.xpack.ilm', 'TRACE'
+  /*
+   * In TimeSeriesLifecycleActionsIT.testWaitForSnapshotSlmExecutedBefore() we create a snapshot, then associate an ILM policy with an index, and
+   * then that policy checks if a snapshot has been started at the same millisecond or later than the policy's action's date. Since both the
+   * snapshot start time and policy are using ThreadPool.absoluteTimeInMillis(), it is possible that they get the same cached result back (it is
+   * kept for about 200 ms). The following config changes ThreadPool.absoluteTimeInMillis() to always use System.currentTimeMillis() rather than a
+   * cached time. So the policy's action date is always after the snapshot's start.
+   */
+  setting 'thread_pool.estimated_time_interval', '0'
   systemProperty 'es.rollup_v2_feature_flag_enabled', 'true'
 }