refactor: replace ops-tracing vendored libs by Charmlibs versions

[dwilding]

Fully agent generated. I haven't reviewed yet.

[james-garner-canonical]

IIRC Ops needs to register its copy of the tracing library object under a different name to avoid clashing with the objects registered by charms using the same lib. I don't recall where we made this edit in the vendored lib or where we could make this adjustment to the PyPI lib (monkeypatch? subclass?). But I guess an agent should be able to take a crack at it.

Presumably this is why the observability tests fail.

[tonyandrewmeyer]

IIRC Ops needs to register its copy of the tracing library object under a different name to avoid clashing with the objects registered by charms using the same lib. I don't recall where we made this edit in the vendored lib or where we could make this adjustment to the PyPI lib (monkeypatch? subclass?). But I guess an agent should be able to take a crack at it.

Presumably this is why the observability tests fail.

I misremembered which library it was, it's certificate transfer, the "internal" prefix. And it is definitely the cause for the observability test failure. I would also assume subclassing or similar can work around it.

[dwilding]

That was it, thanks! My agent added subclasses in f0b625a. (Again, not yet reviewed by me)

[dwilding]

The Data Charm Tests failures are because the tracing lib was released too recently for Poetry (in downstream charm repos) to resolve. Should pass tomorrow.