Remove object.__setattr__ frozen bypasses

[tonyandrewmeyer]

I think we're all agreed that it would be nice if we didn't have to have a bunch of object.__setattr__(self, "attribute", new_value) in the state (while still keeping the immutability that the frozen dataclasses provide).

A few of these are in __post_init__ and probably need to stay as they are. The majority are handling components of the state being changed during the event - new secret content, opening/closing ports, setting the unit/app status, etc. It would be nice to keep the immutability but avoid the object.__setattr__ for those.

[tonyandrewmeyer]

One thought: what if we had a (meta? sub?) class that behaved like the normal frozen dataclass, but was private, and had a freeze() method that would return the normal frozen dataclass? And instead of doing a copy.deepcopy of the state, we'd copy it into these mutable classes, let the mocking modify things as they normally would, and then when setting the output state, provide the frozen version.

[PietroPasotti]

yes I like the idea of having an unfrozen ('molten'?) state version for mocking to manipulate during charm execution, and then return its frozen version back to the userspace when we're done.