Fix average pass duration algorithm

[beaufortfrancois]

As discovered in https://bugs.chromium.org/p/chromium/issues/detail?id=1504013#c5, the average pass duration algorithm was misbehaving because the t variable was not captured properly. This PR fixes this issue.

This diff will hopefully help reviewers:

@kainino0x Please review.

[toji]

Ah, sorry I didn't see this before implementing my own fix: #329

My code includes rejection for negative durations, which was causing some of the timestamp instability. It also coincidentally sidesteps this capture problem by no longer using t to decide when to update the UI.

[beaufortfrancois]

I wasn't able to get negative durations on my Pixel 7 device. Is there a specific config that is needed to reproduce?

[toji]

I haven't tested with the Pixel 7 but on a Pixel 4, 6, and 8 I've seen them come through occasionally, as well as devices from other manufacturers. Also worth noting that timestamps on Android are a bit bugged right now, which I'm in the process of fixing.

[kainino0x]

Sorry, I only saw this after Brandon sent me his change. Nice catch about the broken t variable! Fortunately, Brandon's change also fixes this capture issue by using a different variable that only changes inside the promise callback.

Though this does have me wondering if we need to strengthen the ordering guarantees in the spec - ring of map buffers is going to be a common pattern and if they resolve out-of-order then I could imagine strange things happening in an application.

This diff will hopefully help reviewers:

FYI GitHub can also do this:

[kainino0x]

BTW when I originally prototyped the averaging code I did not see this bug on Mac, but then yesterday when I loaded it up again I was noticing it there too. (M1 Pro)

[kainino0x]

Wait, no, that was probably just this bug, not the negative timestamp one.