refactor: remove dependency on ops.testing

[tonyandrewmeyer]

The goal is that after doing pip install ops[testing] you can run code like:

from ops import testing

ctx = testing.Context(MyCharm)
ctx.run(ctx.on.start(), testing.State())

Basically: everything that Scenario exports will be available in the ops.testing namespace. This means that Scenario importing from the ops.testing namespace is problematic, because the imports end up being circular.

To avoid this, ops has moved the actual Harness code into a new ops._private.harness module (ops.testing now just handles setting up the namespace). This PR adjusts for that change, importing from ops._private.harness instead of ops.testing.

Rather than just switch to this and require ops 2.17, I've adjusted the imports to work for either case (ops 2.15+). This is messier, but avoids forcing to update their ops and also means that we don't need to wait for two ops releases (potentially two months) in order to make the second change there. There's already a bunch of code to handle other (nominally private) changes in ops 2.16 and 2.17, so a bit more doesn't seem to hurt (for a short time - it will be good to clear all this out soon).

In addition, Scenario already defined a CharmType type, so use that consistently rather than using that in some cases and ops.testing.CharmType in others.

There's one technically breaking change: ActionFailed requires the state argument to be passed by keyword. Tests shouldn't be creating ActionFailed objects so this should have no impact on anyone. This will make it easier to handle the clash between Harness's ActionFailed and Scenario's ActionFailed.

[benhoyt]

Yeah, the TestingPebbleClient thing is a bit messy. Let's brainstorm a little bit during daily sync. I wonder if we can just wait till after this code lives in the ops repo?

[tonyandrewmeyer]

Let's brainstorm a little bit during daily sync.

Sure.

I wonder if we can just wait till after this code lives in the ops repo?

We can definitely do these in the opposite order, or in a single PR. However, the circular issue will still exist, unless we don't add Scenario's code in a new top-level location outside of ops (which is the cleanest for having multiple packages, but could be worked around), or we don't have both Harness and Scenario in the same ops.testing namespace.

For the Pebble test client, another option would be late importing. The Scenario test Pebble client could contain an ops.testing._TestingPebbleClient rather than subclassing from it and have a bunch of wrapper methods, and the import could be done at instantiation time. Or the class could still subclass but the class could be defined only in the get_pebble method with a lazy import there. My guess is that doing either of these would be regretted in the future.

[tonyandrewmeyer]

We're going to move the existing ops.testing code to ops._private/, so this can be reworked to use that after that's done, and can avoid the duplication, just changing the imports instead.

[tonyandrewmeyer]

This should be ok now, but it needs the ops change done first (and released) and then I've also assumed that #191 will get done first as well. I'll move it from draft after those.

[tonyandrewmeyer]

This should be ok now, but it needs the ops change done first (and released)

I've adjusted the PR so that it doesn't need to have the ops change released, because that would slow things down a lot and it would be great to get this piece finished.

[PietroPasotti]

LGTM!

[tonyandrewmeyer]

Drat, I I think I accidentally merged my way out of this one getting a release :(