Separate the 'context' and 'side effects' aspects of the context

[tonyandrewmeyer]

The context has a bunch of "this is the context the event runs in":

• charm_spec
• charm_root (in terms of what's there when the event starts - anything the charm writes to it is more state)
• juju_version
• app_trusted

But there's also a lot of side-effects, which have grown noticeably in 7.x:

• juju_log
• app_status_history
• unit_status_history
• workload_version_history
• requested_storages
• exec_history (TBC)
• removed_secret_revisions
• emitted_events
• action_logs
• action_results

I feel like it would be cleaner if Context was more cleanly just the context (plus config, like the settings for capturing events), and the side effects were available some other way.

[tonyandrewmeyer]

This is just spitballing here, but what if the side-effects were only available when you ran the event with the context manager, so all of those attributes moved from Context to Manager, filled when you did mgr.run()?

It's more of a hassle to use them but it does feel like a more natural fit to me, and most tests shouldn't need to access any of them - two main exceptions being action tests, most of which I assume do want to check the results, and secret-remove events, most of which should be checking that the expected revision was removed.

[PietroPasotti]

I like this suggestion. It also has the benefit of reinforcing the principle that scenario is chiefly a black-box testing thing. If you want to peer into the box, you have to take an extra step.