feat: allow span filtering in service graph processor

[javiermolinar]

What this PR does:
This PR introduces span filtering for the Service Graph processor to prevent the creation of unwanted edges.
Ideally the filters should operate symetrically, discarding the clients and server spans. But since this is heavily depdendent on the intrumentation, it implements a best-effort cache to maintain graph integrity and prevent data skew.

Why:
Currently, the processor accepts every span, which can lead to cluttered or uncontrolled graphs. Some users generate service graphs from external sources (e.g., Grafana Beyla) and need the ability to disable graph generation for specific services within Tempo.

How:
The implementation reuses the spanfilter logic from the spanmetrics processor. To address the risk of creating "orphan edges" (where one side of a connection is filtered but the other isn't), a bounded cache tracks dropped spans:

1. Every incoming span is evaluated against the filter.
2. If a span is rejected, its key and side (client/server) is added to a "dropped spans" cache (a map with a TTL and a maximum element limit).
3. Before creating a new edge, the processor checks this cache. If the peer span exists in the cache, the edge is discarded.
4. TTL expiration and eviction are handled within the existing Expiration goroutine to minimize overhead.

Two new metrics are added:

metrics_generator_processor_service_graphs_dropped_edges_total: increments when an edge is dropped
metrics_generator_processor_service_graphs_dropped_span_side_cache_overflow_total: it increments every time it tries to add a new span to the cache when the max items is reached

Some caveats:

• For simplicity, this cache reuses the existing edge store settings for TTL and max_items. We can monitor the new metrics to determine if independent configuration is required later.

• If the cache is full, new "dropped" markers won't be added until existing items expire. This happens every two seconds. This is a deliberate trade-off to prioritize performance over perfect accuracy.

How it looks in action:

Before filtering

After adding the following filter:

processor:
 service_graphs:
   filter_policies:
     - exclude:
       match_type: strict
       attributes:
         - key: resource.service.name
           value: shop-backend        

The filter only removes the spans specifically tagged with that service name.

Which issue(s) this PR fixes:
Fixes #

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[github-actions]

💻 Deploy preview deleted (feat: allow span filtering in service graph processor).

[javiermolinar]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2e126cacee

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[electron0zero]

few nitpicks, otherwise lgtm.