FunctionEnvMut method for mutably borrowing both store and env

[rachel-bousfield]

Motivation

This feature would improve the ergonomics of FunctionEnvMut<T>.

In wasmer 3.x an &mut impl AsStoreMut, commonly a &mut StoreMut in practice, is needed to modify a Global.

If a FunctionEnvMut<T> carries a Global, then modification requires cloning it since FunctionEnv::as_store_mut() yields the needed StoreMut. This works fine if the FunctionEnvMut<T>'s underlying T is cheap to Clone, but for more complicated FunctionEnv's, one need discard references to produced by FunctionEnvMut::data_mut.

This is awkward, since it means designing host functions like

fn host_foo(mut env: WasmEnvMut) {
    let global = env.data().global.clone().unwrap();
    let mut store = env.as_store_mut();
    global.set(&mut store, 0);
    
    let rest_of_state = env.data_mut();
    // can't use `store` anymore due to `rest_of_state`
    drop(rest_of_state)
    
    let mut store = env.as_store_mut();
    // back to being able to modify globals
}

Proposed solution

We add a new method to FunctionEnvMut<T> that somehow returns both a StoreMut and the underlying &mut T. This would require deeper changes since these currently entail aliasing.

Alternatives

Don't require Global, Memory, and the like need a Store for access as was the case in wasmer 2.x.

We found the upgrade to wasmer 3.x to be quite difficult due to the above. Needing a Store required we re-architect our host functions, using complex types to achieve what used to be given for free.

[svelterust]

Would be really nice to have this.

[ptitSeb]

The new function is now on master. Can this ticket be closed?

[Michael-F-Bryan]

This should be fixed now. @knarkzel and @rachel-bousfield let us know if it's still an issue and we can reopen the ticket.