rethink charm_tracing architecture

[PietroPasotti]

Enhancement Proposal

To help address the decorator and forward-referencing-attrs awkwardness, we could use a different approach. For example:

class MyCharm:
    def _on_tracing_relation_changed(self, e):
        charm_tracing.set_endpoint(self._get_tempo_endpoint(e.data))

    def _on_cert_relation_changed(self, e):
        charm_tracing.set_tls(self._get_ca_cert(e.data))

if __name__ == ...
    charm_tracing.instrument_if_ready(MyCharm)
    ops.main(MyCharm)

[paulomach]

Another argument for the approach is that, the trace_charm decorator has type annotation for CharmBase (ref)

I'm all for type annotations, but for charms that implement some other inheritance, this breaks LSP(pyright) goodies

[PietroPasotti]

that is something that can be fixed with typevars regardless