chore: refactor client_facades and specified_facades shape

[dimaqq]

Description

Streamlining facades code:

• removing intermediate "versions" key from:
  • static facade version declaration
  • specified facades argument
• deprecating the specified_facades argument as it's
  • not covered by unit or integration tests
  • not used by any library user

[james-garner-canonical]

Thanks, I think it would be good to do something like this in future -- or even better, do away with the manually specified client_facades entirely. For now though I would like to avoid refactoring client_facades while we're still ironing out how to validate it and future schemas (3.4 series, 3.5 series, eventually 3.6). We can reopen this if we need to.

[dimaqq]

reopening and moving back to draft; I'll rebase and update this after #1150

[james-garner-canonical]

Closing was probably premature, sorry.

I'd still prefer if we held off on merging this till we finish with #1099.

I know the changes in python-libjuju are pretty minor, but I've been using the current client_facades format in my scripts as the canonical representation for data generated from schemas, from _clientN.py files, from Juju's api/facadeversions.go, and of course client_facades itself. Not to mention introducing the need to handle both formats for client_facades when comparing across commits before and after this change.

All doable to fix, of course, but probably not worth having to fix -- unless this change simplifies work for you?

[dimaqq]

totally fine to sit on this.

[dimaqq]

@james-garner-canonical rebased and updated the test, it's ready for review.

[dimaqq]

/merge

[dimaqq]

/merge

[dimaqq]

/merge