fix(waterfall): Prefer specific root events in trace root lookup

[Lms24]

This PR fixes two issues but to be honest, I'm a bit unsure of all consequences. Would appreciate a thorough review from someone who actually knows the waterfall view :)

1. While fixing fix(waterfall): Relax "next_trace" lookup to just the trace id #104047, I also noticed that we had a similar problem for the "previous trace" button:

   If we look at a trace in the waterfall where the first root span is not a navigation/pageload span but e.g. a web vital span, we can't look up the trace's previous_trace link. Therefore, we can only show the disabled "previous trace" button in the UI, although there actually is a previous trace.

2. For EAP-based traces, it seems like we always took the first transaction event as the title of the current trace. This sometimes led to a bit sub optimal titles in my opinion. I noticed we had a more selective logic for none-EAP events, where we preferred the pageload, navigation and ui.load events over the "first" event.

To fix both of these issues, this PR ports the none-EAP logic of selecting a trace root to the EAP logic. Also kept the heuristic in place to prefer an EAP root event over a none-EAP event in case of mixed traces (?).

Before:

After:

[JPeer264]

For some reason (and this is also not working on master), the very first trace does not have the next button enabled. I could imagine that that worked once. Not sure if this PR is also meaning to fix this behavior.

1. This is the very first trace
2. This is the second trace

[nsdeschenes]

This all makes sense to me, tho would like a second set of eyes on it 😄

[Lms24]

For some reason (and this is also not working on master), the very first trace does not have the next button enabled. I could imagine that that worked once. Not sure if this PR is also meaning to fix this behavior.
This is the very first trace
This is the second trace

I debugged this and found that the environment of the trace root events is the problem here: The 1st trace root (http.server) has development while the second one has production. We filter on the environment in the useSpans call and hence the next trace lookup fails. I think we could just remove that filter but this is a separate issue from this PR. I also want to wait with this and first figure out if the diverging environments are user-configuration or just default config. If it's default, we might just have found a bug in the NextJS SDK 🤔

[JPeer264]

Ya you are absolutely right. The environments are different. I'd be up for removing the env filter

[Lms24]

(This was closed accidentally)

[Abdkhan14]

This makes sense to me!

@Lms24 lets apply the preferred-root logic to to both eap and non-eap traces, getting rid of the isEAPTransaction(event) check. I'm working towards mitigating type-guard usage in this space.

Also, we never expect there to be a mix of eap and non-eap events, we can get rid of eapRootEvent

[Lms24]

Thanks for the review @Abdkhan14. I got rid of the EAP-specific checks. Can you double check if this is still correct? My testing still shows the same behavior as before but I'm not sure if there is anything I missed with non-EAP events (are they even still a thing?)

Update: made two more changes (thx to AI review bots for catching):

• extracted the preferred op lookup
• ensured we still fall back to the first root event

[Lms24]

nice! totally missed this. But I'm not sure if it's actually a concern (see my Q about none-EAP here). Anyway, I extracted the now common logic.

[Abdkhan14]

Exactly what I was talking about 🚢