[ML] Don't try to change the OOM score adjustment when running under Kubernetes

Kubernetes stops processes from changing their OOM score adjustment. There is more detail about this in https://github.com/kubernetes/kubernetes/issues/90973.

This causes the ML processes to log warning messages when running under Kubernetes, which can worry users. To avoid this we should change our code to somehow detect that it is running under Kubernetes and then not attempt to change the OOM score adjustment. We should also keep an eye on https://github.com/kubernetes/kubernetes/issues/90973 to see if this policy of Kubernetes ever changes.

The reason the ML processes increase their OOM score adjustment is similar to the reasoning for PostgreSQL: if the OOM killer has to choose a process it's less catastrophic for it to choose an ML job process than the Elasticsearch JVM.

Assuming our memory accounting is accurate the OOM killer is less likely to be a problem in a container that's dedicated to running Elasticsearch than on a general machine, because there's no chance that the user starts up some unrelated process that consumes a lot of memory. Therefore this adjustment is less important in containers than on general purpose machines, such as development laptops. It only really matters in a container if our memory accounting is wrong under some circumstance, and this makes a job use more memory than its model memory limit plus allowed process overhead.

Finde den Code, der die OOM-Score-Anpassung für ML-Prozesse ändert, und untersuche, wie die Erkennung der Prozessumgebung gehandhabt wird. Prüfe die verknüpfte Kubernetes-Issue auf die aktuelle Richtlinie. Als abgeschlossen gilt die Änderung, wenn von Kubernetes ausgeführte Prozesse diese Änderung nicht mehr zu versuchen oder Warnungen auszugeben versuchen, während das bestehende Verhalten auf Allzweckmaschinen erhalten bleibt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.