[Feature]: provide better structure for referring to trace/span attributes in link patterns

[yurishkuro]

Requirement

As a user defining link patterns I want to have a clear understanding of how the template variables are being resolved, via deterministic and well-defined algorithm.

Problem

Currently the resolution of template variables is rather messy:

• #{foo} in trace-level pattern refers to intrinsic fields like traceID, startTime
• #{foo} in other scopes is looked up in the following order:
  • among other key-value pairs in the same collection (i.e. other log.tags)
  • among span.tags
  • among span.process.tags
  • then recursively repeat the last two steps on span.parent
    Note that intrinsic fields of the Span object are not accessible.

Proposal

The TraceQL design provides a more structured approach to referring to various attributes. If we were to adopt it, it would result in the following changes:

• #{foo} could refer not just to tags, but also Span's intrinsic fields like startTime, serviceName
• keep the priority evaluation when the name is unqualified
  • TBD if we want to keep or remove the ascend through span ancestors. Removing it would be a breaking change.
• support explicit scoping of attributes, i.e. span.foo, span.process.foo, and trace.foo
• for recursive ascend, introduce scopes like span.parent.foo and span.ancestor.foo
• span. prefix ls always optional / implied, i.e. span.process.foo == process.foo, span.parent.foo == parent.foo

Open questions

No response