Don't expose tracing endpoints over cos_agent when backend isn't available

[mmkay]

Issue

When grafana-agent isn't related to a tracing backend, but a charm relates to grafana-agent over cos_agent requesting tracing receivers, charm event hooks take a significant amount of time as the charm tries to send traces to an endpoint that isn't open in grafana-agent.

Solution

Return null when tracing isn't available with a reasonable log message. Fixes #219.

Context

Backward compatibility was tested using https://github.com/canonical/postgresql-operator, observed behaviour:

• if a charm with an older version of cos_agent connects to new grafana-agent and requests tracing endpoints when grafana-agent isn't connected to a tracing backend, its logs will show that the databag wasn't validated. As tracing receivers are the only part grafana-agent returns to the charm in this databag, it doesn't cause any issues, but the charm doesn't try to send charm traces, as desired.
• if a charm with a current (rev13) version of cos_agent connects to new grafana-agent, the following log line will appear:

unit-postgresql-14: 12:08:10 WARNING unit.postgresql/14.juju-log database-peers:81: Endpoint for tracing wasn't provided as tracing backend isn't ready yet. If grafana-agent isn't connected to a tracing backend, integrate it. Otherwise this issue should resolve itself in a few events.

There's also an open question of whether grafana-agent (and grafana-agent-k8s) should be put into blocked state if a charm requests tracing, but grafana-agent isn't connected to the tracing backend. So far I think this should be a separate issue (and will create one once we agree on it), but I might be convinced otherwise.

Testing Instructions

Deploy the following bundle with a local build of grafana-agent from this branch.

default-base: [email protected]/stable
applications:
  grafana-agent:
    charm: grafana-agent
    channel: local
    revision: 0
  postgresql:
    charm: postgresql
    channel: 14/edge
    revision: 530
    num_units: 1
    to:
    - "2"
    constraints: arch=amd64
    storage:
      pgdata: rootfs,1,1024M
machines:
  "2":
    constraints: arch=amd64
relations:
- - postgresql:cos-agent
  - grafana-agent:cos-agent

Observe that connection exceptions in postgresql no longer appear in juju debug-log.

Upgrade Notes

[MichaelThamm]

What is the purpose of calling the requested_tracing_protocols method here versus in the for loop (original functionality)?

[MichaelThamm]

Looks good overall, but worth having a tracing member review the details as well