Use Performance.now in calculating user timings

[jaredhirsch]

Writing client software is full of surprises! Performance.now() is monotonically increasing, Date.now() is system clock-dependent. We should use Performance.now() instead.

I suspect we had a user's system clock update during a Screenshots interaction on Sunday, 1/28. We use Date.now() to generate start and end times, and one ping must have been on the order of hundreds of thousands of seconds, which suggests a system clock update, lol.

---

More details:

This past Sunday, 1/28, the average (mean) time from clicking the Screenshots context-menu item, to the overlay appearing, was 175 seconds (link):

If we take the average of the highest value in each bucket (assuming all pings in the 0.1-1 second bucket took 1 second, etc.), up to the 3600 second bucket, the average comes out to about 21 seconds:

(1570*1 + 286*5 + 163*10 + 217*60 + 20*600 + 5*3600) / (1570 + 286 + 163 + 217 + 20 + 5) ~= 21

This simplifies to 47650 / 2261 ~= 21, which can be rounded off to 50000 / 2000 ~= 20 sec.

The 2 outlier points in the 3600+ bucket have to raise the average up to 175 seconds:

20 sec + (2n / 2000) ~= 175 sec.

Doing a little algebra, or just plugging in some random values for 2n in the JS console, it looks like 2n is roughly 300000, which is clearly absurd: 300,000 seconds is about 3.5 days.

However, if someone's system clock was about 3.5 days behind, and got updated between the context-menu click, and the overlay being shown, that would explain the anomaly.

Refs #4036