Expose a top level charm source directory robustly

[balbirthomas]

Use Case

The Prometheus charm provides a library with Provider and Consumer objects. Prometheus itself is a consumer, hence its metadata.yaml has a requires clause. In order to write a unit test for the Provider object using ops test harness it is necessary to construct an alternative metadata.yaml with a provides clause and use this to instantiate the test harness charm. The Provider object reads alert rules from files on disk and forwards these rules to the Consumer (Prometheus charm). Hence the Provider object needs to know the top level charm source directory path relative to which it can search for the folder containing alert rules (one file per rule). However the operator framework determines a charm's top level source directory using the path of source files from which the charm's metadata (or the action metadata or charm config) was obtained. Hence when the test harness constructs charm classes which do not obtain their metadata from files on disk (such as those for the Provider Object), the top level source directory (ops.charm.CharmBase.charm_dir) is not set correctly.

In order to work around this limitation it becomes necessary to instrument charm library objects such that the code flows for unit tests cases and production deployments of charms are slightly different. This obviously runs the risk that unit tests fail to exercise critical logic in the charm.

Requested Feature

Provide a charm attribute such as charm_dir that is robustly set independent of the presence of files like metadata.yaml (or actions.yaml or config.yaml). A workable solution in this regard (courtsey @jameinel ) is to use "JUJU_CHARM_DIR which is explicitly passed into the Framework in main()".