[ML] Reduce persistent tasks periodic reassignment interval in ...

[dimitris-athanasiou]

... MlDistributedFailureIT.testLoseDedicatedMasterNode.

An intermittent failure has been observed in
MlDistributedFailureIT. testLoseDedicatedMasterNode.
The test launches a cluster comprised by a dedicated master node
and a data and ML node. It creates a job and datafeed and starts them.
It then shuts down and restarts the master node. Finally, the test asserts
that the two tasks have been reassigned within 10s.

The intermittent failure is due to the assertions that the tasks have been
reassigned failing. Investigating the failure revealed that the assertBusy
that performs that assertion times out. Furthermore, it appears that the
job task is not reassigned because the memory tracking info is stale.

Memory tracking info is refreshed asynchronously when a job is attempted
to be reassigned. Tasks are attempted to be reassigned either due to a relevant
cluster state change or periodically. The periodic interval is controlled by a cluster
setting called cluster.persistent_tasks.allocation.recheck_interval and defaults to 30s.

What seems to be happening in this test is that if all cluster state changes after the
master node is restarted come through before the async memory info refresh completes,
then the job might take up to 30s until it is attempted to reassigned. Thus the assertBusy
times out.

This commit changes the test to set cluster.persistent_tasks.allocation.recheck_interval
to 1s. If the above theory is correct, this should eradicate those failures.

Closes #36760

[elasticmachine]

Pinging @elastic/ml-core

[droberts195]

LGTM

[bleskes]

I would really like to avoid changing production defaults due to test concerns. Can't we set the interval in the tests?

[dimitris-athanasiou]

@bleskes This isn't changing the default value of the setting. It reduces the minimum valid value of the setting to 1s. We could also increase the timeout of the assertBusy to over 10 seconds. However, I don't see the downsides of allowing the setting to go as low as 1s if necessary and it allows us to avoid having slow tests.

[droberts195]

Since this is an internal cluster test we have access to the server objects in the same JVM, so I changed the approach to directly change the interval on the appropriate PersistentTasksClusterService object rather than using settings. I reverted the change to the minimum setting value.