Monotonic clock offsetting

[guybedford]

We just landed a change to StarlingMonkey to support handling the invariants of the monotonic clock by defining an offset based on the difference between the Wizer time monotonic clock and the runtime monotonic clock.

Ideally this should always be maintained in Wizer workflows - so it could be worth investigating this further.

Downstream fix: bytecodealliance/StarlingMonkey@72e7481

[fitzgen]

Wizer doesn't really know anything about the semantics of the imported functions, and trying to add that knowledge seems like an endless task that will always be incomplete. I think it is better to create robust code in places like wasi-libc and other fundamental libraries that will handle particular cases that they know the semantics of and which are finite in number. For monotonic clocks in particular, something like the starlingmonkey fix or this

static MAX_TIME: AtomicU64 = AtomicU64::new(0);
let time = raw_wasi_monotonic_clock_now();
let mut max_time = MAX_TIME.load(Acquire);
let time = std::cmp::max(max_time, time);
while time > max_time {
    // XXX: not 100% sure on these orderings, but also shouldn't matter
    // in practice for single-threaded Wasm.
    match MAX_TIME.compare_exchange(max_time, time, Acquire, Acquire) {
        Ok(_) => break,
        Err(new_max_time) => max_time = new_max_time, 
    }
}
return time;