[CI] XPackRestIT test {p0=ml/validate/Test job config that is invalid only because of the job ID} failing

[fcofdez]

Build scan:
https://gradle-enterprise.elastic.co/s/f56oj4ypkuqyo/tests/:x-pack:plugin:yamlRestTestV7CompatTest/org.elasticsearch.xpack.test.rest.XPackRestIT/test%20%7Bp0=ml%2Fvalidate%2FTest%20job%20config%20that%20is%20invalid%20only%20because%20of%20the%20job%20ID%7D

Reproduction line:
./gradlew ':x-pack:plugin:yamlRestTestV7CompatTest' --tests "org.elasticsearch.xpack.test.rest.XPackRestIT.test {p0=ml/validate/Test job config that is invalid only because of the job ID}" -Dtests.seed=92F388027EF5C9C0 -Dtests.locale=es-GT -Dtests.timezone=Asia/Tbilisi -Druntime.java=11

Applicable branches:
master

Reproduces locally?:
Didn't try

Failure history:
https://gradle-enterprise.elastic.co/scans/tests?tests.container=org.elasticsearch.xpack.test.rest.XPackRestIT&tests.test=test%20%7Bp0%3Dml/validate/Test%20job%20config%20that%20is%20invalid%20only%20because%20of%20the%20job%20ID%7D

Failure excerpt:

java.lang.Exception: Test abandoned because suite timeout was reached.

  at __randomizedtesting.SeedInfo.seed([92F388027EF5C9C0]:0)

[elasticmachine]

Pinging @elastic/ml-core (Team:ML)

[droberts195]

The ML test only took 1.2 seconds, so was not responsible for the timeout. It just happened to be the one running when the suite timed out.

Looking at the test timings the tests that took a long time were snapshot/restore tests.

But also, this is a Darwin CI run, where we're running a workload designed for machines with 128GB of RAM on machines with 32GB of RAM, so it's not surprising it fails most of the time. This problem is covered by #58286.