feat(client-only-schemas): replace existing schemas with latest client schemas

[james-garner-canonical]

Replace existing 3.1.X and 3.3.X schemas with the latest client only schemas for versions 3.1.9 and 3.3.6. Regenerate code by removing juju/client/_client*.py and running make client. Update juju/client/connection.py with facades from juju 3.3.6 api/facadeversions.go (a superset of the facades from 3.1.9).

Description

Moving towards the goal of having schemas and generated code in python-libjuju only for the latest supported Juju versions (3.1.9, 3.3.6, 3.5.4, 3.5.3), and using client only schemas (see #1099), this PR replaces the older 3.1.X and 3.3.X schemas with client only schemas for the latest releases of these minor versions (3.1.9 and 3.3.6), regenerating code as described above.

QA Steps

CI steps should all continue to pass, except for integration testing which should continue to fail with the usual suspects (see #1108 for a non-exhaustive table of tests that sometimes fail on main).

Notes

To hopefully simplify the diffs, this is the second PR in a planned sequence of PRs.
Previously merged:

1. feat(client-only-schemas): remove schemas for EOL Juju 3.2 #1113

Subsequent PRs will be:
3. add client only schema for 3.4.5 and regenerate code
4. add client only schema for 3.5.3 and regenerate code

[james-garner-canonical]

/build

[dimaqq]

A whole lot of failed tests on "supported-series"
I wonder if some juju code relied on specific facade version and needs to be updated or what.

[james-garner-canonical]

Yes this definitely needs more work. I'm going to break it down into just going to 3.1.9 and 3.3.6 (and maybe try those separately), and then as a subsequent step switch to using client only, to see where exactly things break. See also this comment from Simon on the Juju client schema PR suggesting that the controller schema may be needed as well. Happy to receive additional feedback on this approach in this PR, but it's definitely not ready to merge for now.

[dimaqq]

Ah, perhaps I missed that. We need model-user group to eg list apps on a model and controller-user group to eg list models on a controller.

[james-garner-canonical]

Current version of this PR now only replaces 3.1.X and 3.3.X with the latest schemas (3.1.9 and 3.3.6), using the full schema rather than the client only schema. Integration tests seem to still be similarly broken ("supported-series" / "supported_series"), so there may be something very wrong with this approach. I'll investigate further.

[james-garner-canonical]

I figured out the proximate cause of all those extra tests failing with "supported-series" -- by restoring juju/client/connection.py to the version on main, we get back to only the usual 5 or so unit tests that fail on main. This seems to work regardless of whether we use facades generated from the original full schemas (3.1.0, 3.1.1, 3.1.2, and 3.3.0) or we use facades generated from the latest client-only schemas (3.1.9 and 3.3.6).

The only change to connection.py was changing the client_facades dict to match juju's api/facadeversions.go, as mentioned in the initial PR description:

Update juju/client/connection.py with facades from juju 3.3.6 api/facadeversions.go (a superset of the facades from 3.1.9).

I think my mistake was replacing the old facade versions with those listed in juju 3.3.6, rather than instead adding any new facades -- that is, as long as we're supporting the same minor versions, facades should never be unlisted here.

But this is a little weird, because using only client-only 3.1.9 and 3.3.6 schemas leads to _client18.py no longer being generated, while client_facades will still have 'Uniter': {'versions': [18]}.

Note that removing the 3.2.X schemas entirely as in #1113 (which I merged) leads to all of _client{8, 12, 13, 14, 15, 16}.py not being generated. That PR doesn't touch connection.py. While 8, 12, and 13 aren't present in client_facades in main, there is 'Application': {'versions': [14, 15, 16, 17, 19]} which includes 14, 15, and 16.

[dimaqq]

Done in #1179