Add support for exec "service-context"

[benhoyt]

This is Pebble PR canonical/pebble#246

Also add working_dir field to pebble.Service and flesh out types for HttpDict, TcpDict, and ExecDict.

This is the ops part of OP034.

We should also document this at https://juju.is/docs/sdk/interact-with-pebble once this is merged.

[jameinel]

Is there anything where we should be checking the Pebble version and giving users nice messages if this feature is/isn't supported?

[jameinel]

How did these get so out of sync with what you can put into them? Presumably because they are just dicts (so you could have always passed additional information there).
But that also implies that we are missing test cases that the extra fields have any impact on the requests.
I suppose mostly these are just curried to Pebble, and all the testing should happen at that level.
It does feel like we are missing something about the contract with an external system
(for example, someone might spell it service_context vs service-context, and while the typeddict will catch with a linter, it would be nice to have some form of validation that it matches what pebble actually expects)

What if pebble had a "validate these arguments" mode, where it didn't actually run it, but at least validated the content, and then an ops test that if it doesn't see pebble in the path, just gets skipped, but otherwise asks to validate args that we want to pass?

[benhoyt]

These types only just became public (in ops 2.4.0), so that's probably the main reason. I wanted them to be public so people could use them to type check their pebble.LayerDicts in their charms. If people are using this new type annotations for their dicts, it will check them (though they don't have to).

Separately, we're planning to add a --dry mode for validating layer config to Pebble (canonical/pebble#214). But I think additional work here is out of scope, at least for now.

[benhoyt]

@jameinel I've updated the PR to add JujuVersion.supports_exec_service_context and used that in Container.exec to give a nice error if they're on a non-supporting version of Juju. I think I've got the Juju versions right, assuming juju/juju#15909 goes in and is merged forward.

[jameinel]

fwiw, 3.2.1 isn't "out" it just is a burned release number so nobody will ever run it.

Anyway, are we sure that this is a true statement? Have we already landed the pebble changes into the juju branches such that the next releases will have the service context?

Would this read cleaner as:

if (self.major, self.minor, self.patch) < (3,1,6):
  # First released in 3.1.6
  return False
if (self.major.self.minor,self.patch) == (3,2,0):
  # 3.2.0 was released before pebble was updated, but all other 3.2 releases have the change
  return False
return True