Simplifies summary logic by not doing skew correction

[codefromthecrypt]

The trace summary screen and individual trace screens are served by
different data. At the moment, offsets are not considered when computing
the trace duration broken down by service. Maybe it should be, but
removing clock skew makes migration to v2 simpler and we can then
revisit this logic.

See #2217

[codefromthecrypt]

To test this, I used "skew.json" before and after the change and noticed the service percentage was exactly the same. This is how I know the percentage function doesn't consider offset even without looking at the code (I also looked at the code though!)

[tacigar]

I think that is good!
But I have a question.

I think that adjustTimestamps in skew.js may change the timestamps of the spans, and traceDuration in traceSummary.js will be used for duration calculation.
And I think that in many case traceDuration function returns span[0].timestamp + span[0].duration - span[0].timestamp (== span[0].duration).
So in many case, I think the process of clock-skew is unnecessary.
Is my opinion correct?
And is this even in all cases?

Sorry for newbie question 😞

[codefromthecrypt]

This may indeed be a problem. I will look into it now as we don't have data yet to break this.