Make it more clear that it's about the vertical tolerance only.
Also correct the interpretation at the end. Inclusive retains more details, while exclusive makes parts fit better, not the other way around.
Contributes to issue #6093.
It turns out that we have another bug in Uranium: Transformations from 3MF files are not applied to the platform mesh. This makes sense because UM.Scene.Platform takes the mesh data (without transformations) from the node that it read and squashes that into the SceneNode for the platform. This SceneNode already has a transformation for the platform offset. The 3MF node also has a transformation from the 3MF's convention to have the origin in the front left. The 3MF reader then squishes the transformation from the node into that.
To fix this we'd need to either:
* separate the transformation of the 3MF file from the transformation from the 3MF convention to have the origin in the front left, so that we can pick and choose, or
* remove the transformation from the 3MF convention and apply it only on loading normal printed meshes, and then modify all of the 3MF platform files.
Both require significant effort. So instead I applied the transformation directly to the vertex data.
To do that I imported the file into Blender using my own Blender plug-in, exported to STL and imported that STL again to apply the transformations, and then exported the file from Blender again.
In Blender I also combined a lot of flat faces together, which reduced the file type losslessly.
Contributes to issue CURA-7534.
The position argument metadata always be there. However if it's not (because the file is old, or manually modified, or a version upgrade worked incorrectly, or whatever) then we shouldn't crash. We just don't know how to order it correctly then. This tries to repair it as best it can.
For instance if the file name is too long for this file system, if the computer is running out of disk space or if there is a general failure to write here.
Fixes Sentry issue CURA-YQ.
Previously it would just re-try all settings, but this really isn't needed (since
we have a setting relationship object that can tell us what settings depend on what).
This won't speed things up in a worst case scenario (since that will still be "caluclate
all the settings") but it will speed it up in most cases.
Most setting changes now only trigger a calculation that takes <0.2 sec isntead of the 1.1 sec.
Yes, those numbers seem big, but the error checking is already built in such a way that it spreads this
out over multiple frames (so it's not actually freezing that time, but it is doing shit it shouldn't do!)
CURA-7106
