Clean up tracing databag in v3

[mmkay]

Enhancement Proposal

In tracing v2, we made several choices about the structure of the databag. Provider side exposes:

- host - used to build internal URL. Doesn't contain the scheme
- receivers - list of supported receivers with their ports
- external_url - when ingress is there, it's the ingressed URL, it contains the scheme
- internal_scheme - optional, used in combination with host (and receivers) to build the path. Can be either 'http' or 'https'

This structure has its quirks as we wanted to keep as backwards compatible as possible:

• there's a difference between building tracing URL for ingressed and non-ingressed scenario, causing unnecessary complexity in tracing.get_endpoint logic
• we have fields that are conditional

We could do one of the following:

Option 1:

• the databag contains only receivers. Each receiver contains a full URL, with scheme and port (however without the exact API path - some instrumentation libraries add it themselves). If Tempo is behind ingress, it is the ingressed URL, otherwise the internal one. This means that in all relations (regardless if they're in-model or not), if ingress is there, it is the only advertised option to pass traces.

Option 2:

• the databag contains receivers like it does now, but there are external_url and internal_url fields, both containing scheme. get_endpoint then appends port number and URL that belongs to the right protocol.

[PietroPasotti]

question: do we always need to give an internal url?

This is how the provider databag could look like: addresses: []

• {type:http, url:http://traefik_address:2331}
• {type:http, url:https://traefik_address:2331}
• {type:http, url:http://tempo_public_ip:2331}
• {type:http, url:https://tempo_public_ip:2331}
• {type:grpc, url:tempo_public_ip:2331}
• {type:grpc, url:traefik_address:2331}

[PietroPasotti]

todo: determine if we can drop v1 (does cos-lite stable charms still use it?) or we need BC with v1 and v2 todo: update charm-relation-interfaces

[PietroPasotti]

decision: so long as nobody's using it

• we can drop v1 and v2 support
• push v3 charm lib to cos-lite and release on stable
• release tempo v3 to stable

[PietroPasotti]

let's see if we can keep the changes contained to the interface and keep the charm-facing API the same, so we don't have to bump the charm lib major, but only the interface.