Some brim settings seemed to behave as if they where linked, when in fact for any extruder set to -1 the 'default extruder' was set by some hacky code that supposedly fixes a 'dissallowed area' issue, very likely also related to the skirt/brim settings. Since dissalowed area for skirt/brim will not be a thing anymore, at least in the front-end, due to CURA-9066 (the 'parent' jira ticket that was blocked by this bug); it was sinplest just to remove the hack altogether. (Otherwise we'd have to make an artificial distinction between -1 and None as it relates to 'Not Set/Used' versus 'Not Overridden', only to then force it back to -1 in situations that call for it -- like communicating to the engine.)
CURA-9553
The stacks would get marked dirty for setting some metadata, but since thats
part of their construction, they aren't really dirty.
Previously, every single stack that was loaded would be marked as dirty, which causes unneeded
saving.
This was originally added for backwards compatibility with old versions of Uranium. However the link between Cura versions and Uranium versions is already very strong (Cura crashes with old Uranium versions) so this is not necessary.
It was also adding warnings in our log that these extruders had already been added to the printer.
Done during Turbo Testing and Tooling, to clean up our log files.
This is a relic from when you first had to add the metadata entry. Now it does nothing any more because it's being set directly afterwards to the actual value that is desired in the end.
Contributes to issue CURA-5876.
ContainerRegistry.
That will be very helpful for creating unit tests. Also this is not
needed because the next stack is always set in the machine or extruder
manager when switching printers.
Contributes to CURA-5628.
The 'parent' parameter was unused, so I removed it. But I didn't remove all things that called it, apparently. I just removed some. I didn't try the stackbuilder.
Contributes to issue CURA-5330.
Not all extruder stacks have a next stack. Well currently every extruder stack should have a next stack, but the code is built around the possibility that there isn't a next stack elsewhere too.
Contributes to issue CURA-4121.
We do not load the extruders in a fixed order, thus we cannot assume
that addExtruder is called in the right order. This means that index 0
of the extruders is not necessarily the extruder with position 0. So
instead, use the extruder position as a dict key.
Contributes to CURA-3738
