wasmtime: Make StoreContextMut accessible in the epoch deadline callback

[saulecabrera]

This commit changes the signature of the Store::epoch_deadline_callback to
take in StoreContextMut instead of a mutable reference to the store's data.

This is useful in cases in which the callback definition needs access to the
Store to be able to use other methods that take in AsContext/AsContextMut,
like for example WasmtimeBacktrace::capture

I decided to only pass in StoreContextMut as the data is accessible through it
via dataand data_mut, but also happy to have them both if there are specific
reasons to do so.

[github-actions]

Subscribe to Label Action

cc @peterhuene

Details

This issue or pull request has been labeled: "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

• peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[alexcrichton]

Thanks!

My main point of hesitation is that giving out a StoreContextMut is a pretty big "power up" from the prior interface where you only get access to T. Notably the "weird thing" you can do is to recursively invoke more wasm given that you've got the whole store on hand. That's not necessarily a bad thing, though, it's mostly just one where any update to the boundary of Wasmtime and its runtime needs to be carefully scrutinized since we can't rely on Rust's type system to catch errors.

One reason I'm hestitating here is that we don't currently have precedent for this. None of the other libcalls hand out StoreContextMut<T> to the closures provided. Everything else only operates on the &mut T I think which means that this would be the first of its kind in terms of handing out the whole store. The closest analog is host-defined functions which get access to the whole context.

Thinking about this though I don't think that there's any issues here. I believe mutability of the whole store is threaded through correctly so no borrowing violations or such should be happening. Given all that, while it would be weird to recursively invoke wasm in this callback, I believe it's safe to do so.

I've got one minor comment, but otherwise looks good to me 👍