Update vendored libraries in ops[tracing]

[dimaqq]

tracing.py

Ours it patch 6, the latest is patch 11

Upstreams:

• https://github.com/canonical/tempo-coordinator-k8s-operator/commits/main/lib/charms/tempo_coordinator_k8s/v0/tracing.py (2 bug fixes)
  • catch modelerrors only on request_protocols call in init tempo-coordinator-k8s-operator#134
  • catch error on charm-tracing-config if leader databag is empty tempo-coordinator-k8s-operator#150
• https://github.com/canonical/tempo-operators/commits/main/coordinator/lib/charms/tempo_coordinator_k8s/v0/tracing.py
  • mostly stylistic, types and ignores
  • logging API udpate from f-strings to %s

certificate_transfer.py

Someone needs to check the details

Upstreams:

• https://github.com/canonical/certificate-transfer-interface/commits/main/lib/charms/certificate_transfer_interface/v1/certificate_transfer.py
  • tbd
• https://github.com/canonical/charmlibs/tree/main/interfaces/certificate_transfer
  • tbd

[james-garner-canonical]

Can we switch to using charmlibs-interfaces-certificate-transfer from PyPI?

[james-garner-canonical]

Oh and if we're going to migrate the tracing lib to charmlibs too, then I guess ideally we would hold off on updating our vendored copy and switch to that instead too.

[dimaqq]

Can we switch to using charmlibs-interfaces-certificate-transfer from PyPI?

That's something that would need to be prototyped.
The issue I see is that we'd depend on a package that depends back on ops.
So we'd need to figure out dep version ranges / policy in advance.

[benhoyt]

Closing in favour of #2557 or whatever we decide instead.