journald: remove span field prefixes; add separate fields for span data

[wiktorsikora]

Motivation

Currently, tracing-journald prefixes event fields with the number
of parent spans, if present, in order to namespace field values. This
turned out to be unnecessary as journald preserves values for duplicated
field names.

Solution

This branch removes event field prefixes and emits parent span names
and their field/value pairs as additional key/value pairs.

[hawkw]

thanks for working on this! i noticed a few things we may want to address before this is ready to merge --- in particular, i think the relationship between the span field prefix and field prefix configurations seems a bit surprising.

also, it would be nice to hear from @Ralith before merging this.

[Ralith]

I didn't actually realize journald preserved values for duplicate field names. Maybe we should drop the span prefixes entirely? This would be breaking, but probably gives more intuitive/natural results in the common case.

We definitely want a custom prefix for span names and built-in metadata (SPAN_NAME, SPAN_CODE_LINE, etc. maybe?) but perhaps not for user-defined fields.

[wiktorsikora]

Thanks for review. I have applied suggestions.

I agree it would be less confusing to disable prefixing of the user span fields by default.

Is there anything else I could do on this?

[Ralith]

I agree it would be less confusing to disable prefixing of the user span fields by default.

What about removing support for prefixing spans entirely? It seems superfluous to me in light of journald's behavior as tested here. I'm not sure anyone actually wants the current behavior, even as an option. I'd also like to get @hawkw's input on the compatibility break, too; if we go this way, it should probably be 0.2 so it doesn't catch anyone relying on the current behavior by surprise.

[wiktorsikora]

I removed span fields prefixing. I also added SPAN_NAME field emitted for events recorded inside spans.
As @Ralith pointed out, these are breaking changes.

[wiktorsikora]

@hawkw is there anything else I could do on this? No pressure, I just want to know :)

[hawkw]

i think this looks good to me, thanks!

[psztoch]

When will these changes go to the master?
The proposed changes are VERY desirable.