[release/7.0-staging] [browser] fix job queue timespan calculation

[github-actions]

Backport of #85677 and #85660 to release/7.0-staging

/cc @pavelsavara

Customer Impact

"Scheduled tasks stop working after 2023.04.14 1:41:36 UTC"

Fixes #85473

Testing

Unit tests and manual testing.

Risk

Limited to wasm platform, mainly Blazor wasm.

[carlossanlop]

@pavelsavara - Reminder that you're free to merge your PR to the staging branch anytime, as long as:

• It has been approved by Tactics (Servicing-approved label applied).
• Signed-off by an area owner.
• CI is either green, or the failures are investigated and considered unrelated.
• OOB package authoring changes are added if needed.

If you want this fix to go into the June Release, please make sure to merge this before the code complete day (May 15th).

[pavelsavara]

Thanks!
CI failures are unrelated.
I will do bit more testing before I send the email to tactics.

[pavelsavara]

It seems that time_t is 32bits in Net7 and 64bits in Net8 wasm.

We use emscripten version 3.1.12 in Net7
This seems to be the real fix emscripten-core/emscripten#17401
The fix is in 3.1.16.

[pavelsavara]

We are not going to upgrade emscripten on patch. Especially when it's breaking ABI.
The change to monotonic clock we did here switches the underlying function to __clock_gettime -> _emscripten_get_now -> performance.now.

performance.now returns milliseconds since browser window start.
That is much smaller number than Date.now we had so far, which starts 1970-1-1.

The ts->tv_sec which is overflowing 31bits, will overflow in about 24000 days after the browser window was opened.
Because https://github.com/emscripten-core/emscripten/blob/d1530e7dd9c1d309fddd51b7d4b7201ec2cf3fd6/system/lib/libc/emscripten_time.c#L59-L60

I guess that's as good fix as we could get for Net7.

[pavelsavara]

Approved in email with Tactics.
CI timeouts are known and unrelated.
Merging