Rework Model Context

[simlang]

Description

This PR refactors the ModelContext abstraction
Before the ModelContext used the incoming pipeline as a storage, for the smashed model, now the context itself is returned to get resources from.
Using pipeline as storage device, lead to problems when e.g. using the combination hqq+torch.compile

The changes include:

1. instead of providing: pipeline, working model and denoiser_type, only provide model_context and working_model (denoiser_type was only used by one algorithm and can now be accessed via model_context.denoiser_type if needed)
2. at end of smashing, set_smashed_working_model(smashed_model) has to be called to tell the context, that the working model has changed
3. on context exit, the internal state of the pipeline/model given to the context is updated, but only if set_smashed_working_model has been called before - otherwise nothing happens. This allows us to use the context also, if the working model is not adapted
4. since the model given to the context might be immutable (if it's the working model and not a pipeline) we can't directly change it - this means to get the updated pipeline/model we have to call model_context.get_smashed() to return after smashing

Related Issue

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Locally ran all tests for algorithms which use ModelContext

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Additional Notes

There might be a point of moving the ModelContext to the apply wrapper, to avoid duplicate code

[gsprochette]

is there a reason for using this instead of mc.smashed_working_model = working_model and mc.smashed_pipeline from outside?

[simlang]

This self.smashed_working_model = working_model was super cryptic to me, when i first read it before. So i add functions to name what is happening - so just readability

[gsprochette]

I think in all cases the user needs to know what they are doing with the ModelContext, and these setter and getter are adding complexity... Using these variables could be explained within an error raised in the __exit__ if smashed_working_model wasn't set.

[simlang]

i would rename the functions, as with the current names there is not really a difference to just assigning and reading.
i like having this abstraction however, without ever seeing the inside of this context it is hard to understand from the outside what is happening

[gsprochette]

Good job fixing this ! We're using a context in a weird way so we should spend a minute making it extra clear and extra clean, all my comments go in that direction :)

[llcnt]

Thanks again for the fix, it is much more clean :)

[llcnt]

What does this AbstractContextManager provide us ? Any reason why we want our mc to depend on it? :)

[simlang]

tbh nothing - just readability that this is a ContextManager - should i remove it?

[gsprochette]

That's almost ready to go, I left a couple of comments in the read_only check because it can still be improved. Once this is done, you can merge :)

[gsprochette]

We could also check if self.read_only and self.smashed_working_model is not None because this is bound to produce a cryptic bug

[simlang]

also good point!