This PR fixes a bug where the native code overhead that we
assume for the memory needed to load shared libraries was
not considered if a PyTorch model was the first ML process
to load on a node.

Because that overhead _was_ considered after the model had
been assigned to the node this could have caused inconsistencies
such as total assigned memory being greater than permitted,
or repeated autoscaling loops.

There is a complication though, as we want it to be possible to
load a good selection of PyTorch models on 2GB ML nodes in
Cloud. Many models are very close to the limit of what's
possible, and wouldn't fit if the extra 30MB was added in
without changing anything else. (This is particularly the case
when logging and metrics collection is enabled, because then
memory gets set aside for Filebeat and Metricbeat.)

To avoid drastically reducing the selection of models that will
fit on a 2GB node the per-process overhead is reduced from 270MB
to 240MB. Therefore, when there is just one model running per
node this PR has no effect on which models will fit. When multiple
models run on the same node the memory requirement is slightly
reduced compared to before. However, the 270MB was a pretty rough
estimate in the first place, so this is unlikely to be a major
problem.

* [ML] Adjust memory overhead for PyTorch models (#86416)

This PR fixes a bug where the native code overhead that we
assume for the memory needed to load shared libraries was
not considered if a PyTorch model was the first ML process
to load on a node.

Because that overhead _was_ considered after the model had
been assigned to the node this could have caused inconsistencies
such as total assigned memory being greater than permitted,
or repeated autoscaling loops.

There is a complication though, as we want it to be possible to
load a good selection of PyTorch models on 2GB ML nodes in
Cloud. Many models are very close to the limit of what's
possible, and wouldn't fit if the extra 30MB was added in
without changing anything else. (This is particularly the case
when logging and metrics collection is enabled, because then
memory gets set aside for Filebeat and Metricbeat.)

To avoid drastically reducing the selection of models that will
fit on a 2GB node the per-process overhead is reduced from 270MB
to 240MB. Therefore, when there is just one model running per
node this PR has no effect on which models will fit. When multiple
models run on the same node the memory requirement is slightly
reduced compared to before. However, the 270MB was a pretty rough
estimate in the first place, so this is unlikely to be a major
problem.

* Fix test

…in the model assignment planner" (#101853)

The original PR #98874 missed the memory overhead adjustment from #86416. As it caused some BWC test failures on the CI, I reverted it in #101834.

This PR reintegrates the functionality and extends the BWC integration test with the memory constant depending on the version of the old cluster.