test: handle warnings generated by our own tests

[tonyandrewmeyer]

Our tests currently end with a very large list of warnings. This PR fixes that:

• All of the Harness tests emit a PendingDeprecationWarning telling us that Harness is going away and we should use Scenario. This seems like something to simply ignore in our own tests, so I've added a -W argument to Python to silence them in bulk.
• One test_main test raises a warning about controller storage going away - there's another test that tests that warning happens, and the two tests are otherwise identical. I've merged the two - we don't need them both.
• Two of the secret tests check that SecretInfo objects can still be created without providing the model UUID. I've added a pytest.warns to (a) ensure that there's the warning, and (b) stop it appearing in the tox output.
• Scenario should provide the model UUID when creating SecretInfo objects. This is a one-line fix, so I've added it here - it stops deprecation warnings, but is really more the code than the tests, but since it's so small I think it's ok here.
• The context.on Scenario tests check that pre- and post- series upgrade events work, and those raise warnings. I've split them off to a separate test that verifies (and silences) the warning.

Fixes #1408

Some tests are failing

[james-garner-canonical]

Validate PR title: I really think that tests is a better commit type than test, because to me the latter always feels like "this is just a test, not a for real". But here we are ...

Unit tests: looks like catch_warnings fails on older pythons, I guess the __init__ form changed? This makes me think, we should update CI to not have unit tests cancel each other -- it's possible for them to pass on some python versions and fail on others, and it's good to know which ones -- and they're cheap and fast to run so cancelling doesn't really save much anyway.

[tonyandrewmeyer]

Validate PR title: I really think that tests is a better commit type than test, because to me the latter always feels like "this is just a test, not a for real". But here we are ...

I feel like I get this wrong about 50% of the time 😆.

Unit tests: looks like catch_warnings fails on older pythons, I guess the __init__ form changed?

Yeah, a bunch of parameters were added in 3.11, and I'd forgotten that. Maybe I ought to default to running tox with 3.8 locally - it's much more likely that it would catch things than using newer Python.

This makes me think, we should update CI to not have unit tests cancel each other -- it's possible for them to pass on some python versions and fail on others, and it's good to know which ones -- and they're cheap and fast to run so cancelling doesn't really save much anyway.

Interesting thought - feel free to add it to the team discussion topics. I do agree that at times (like this one) it's more informative to immediately see "ah, this is bad on [3.8 or macOS or ..]". At other times, when something is just generally wrong (hopefully only drafts, if one is properly running tox locally) it does feel wasteful to do all the matrix when it's going to fail every time.

[dimaqq]

I wish there was a more elegant way, but I guess given that Harness is deprecated, this will do.

The downside is that we won't notice if Harness is accidentally used in new tests, isn't it? I supposed that would get caught by human review.