fix(frontend): reduce cardinality in next.js spans with processor

[cedricziel]

Changes

Mangle spans so the names dont contain high-cardinality segments.

This actively prevents the scenario for the bring-your-own observability deployment type in the helm chart by fixing the span names locally

Partially fixes the concerns in #2189

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[julianocosta89]

@cedricziel is that an issue with the instrumentation library or with the demo itself?

I feel that renaming the span name, shouldn't be required, and if it is, we should do it in the Collector, not on the code.

[cedricziel]

At this point the root cause is in the instrumentation, but the problem is with the demo.

Weve seen many folks running into extremely high cardinality because the issue is not being fixed in the instrumentation upstream.

This change "fixes" what's broken in order to limit the impact.

The problem I see with collector level changes is that anyone who's trying other collectors or scenarios will run into this - and they might not know

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[puckpuck]

As mentioned in this comment on the original issue, this is fixed if you use the default transform rules we have in the Collector. We should keep to this pattern to fix these high cardinality span names.