We currently work with the YAML file(s) (either charmcraft.yaml or metadata.yaml with optional actions.yaml and config.yaml) quite a lot, particularly in the common "autoload" case when not explicitly providing a charm root directory:

• Whenever a Context object is created, we load the metadata (trying charmcraft.yaml first and falling back to the legacy files if needed) (so 1x open and 1x YAML load)
• With each run, we create a temporary directory and write the three (this is simulating the Juju state) files there (so 3x open and 3x YAML dump), using the (dictionary) data from the charm spec. This directory is discarded after the run.
• With each run, we create an ops.CharmMeta object, reading the text of the file written above from metadata.yaml and actions.yaml (and probably in the future config.yaml) and doing a YAML load.

There's definitely some optimisation possible here.

This is partially split off from #1434 (but that ticket is mostly being treated as regressions from earlier Scenario, and this is not that, although it might result in worse performance when moving from Harness to Scenario).