Reevaluate traceId generation places

[stefanosiano]

Description

There is an "issue" with ANRs not having the same traceId of the currently running transaction, if the transaction finishes right before the ANR occurs.

This is due to our TWP implementation. Should we change it?
It would mean to either

• understand if an anr is likely going to occur and don't overwrite the stored traceId when the current span finishes
• replace the traceId stored from spans only after at least 5 seconds, ensuring that the traceId stored in the PersistingScopeObserver is used only by ANRs

[linear]

JAVA-151 Reevaluate traceId generation places

[lcian]

I think the implementation in the core SDK works correctly, so we might want to add some special logic just for ANRs.

[markushi]

We could also utilize span-links to at least connect different traces, allowing the user to see previous traces and e.g. connected logs.