Add support for the wasm32-unknown-unknown WASM target. Add CI job to maintain support.

[mitchmindtree]

Motivation

Currently at fuel-indexer we're prioritising updating to the latest versions of the fuels-* and fuel-* crates in order to catch up and stay in sync with the Fuel ecosystem FuelLabs/fuel-indexer#20.

Previously, it was thought that the lack of #![no_std] support was a blocker for this, however it appears that what we really need is support for the WASM target which is not the same but imposes similar limitations.

The motivation here is that fuel-indexer supports a WASM plugin system, where users of fuel-indexer can write and share custom plugins based on their application's particular indexing needs.

As the WASM target is designed for execution in quite a constrained context, it has some limitations compared to regular native targets. Most of these revolve around I/O (e.g. file access, accessing the time, etc).

WASM target

@tjsharp1 can you confirm which WASM target we need to support here?

My initial assumption was wasm32-unknown-unknown, but I just noticed this line in the indexer-samples README in FuelLabs/fuel-indexer#32:

cargo r --bin index-runner -- --wasm target/wasm32-wasi/release/simple_wasm.wasm

does that mean the target we want is wasm32-wasi? We'll need to know exactly what target to test for in order to be able to address this.

Edit: Ah, I just noticed the .cargo/config file included in that PR mentions wasm32-unknown-unknown, so it looks like that's the target we want to support!

Crates requiring attention

Crates that currently do not support WASM are:

• fuels-contract
• fuels-signers
• fuels-test-helpers

@tjsharp1 you mentioned each of these have dependencies that do not support the WASM target. Can you share what these dependencies are and what the errors look like? This might help to identify alternatives or see if we need to enable certain features in these dependencies, etc.

CI

We should also add a CI job that at least cargo build's the desired WASM target so that we can maintain support going forward and avoid accidental future breakage.

Potential Temporary Workaround

I thought we might be able to work around this by only using the fuels-* crates that we actually need, however @tjsharp1 raised a good point that fuels itself is exposed in the code generated by the abigen! macro, and it seems this macro is used by the indexer plugins. We could possibly do something along the lines of #317 to enable this workaround, but this might complicate testing for fuels-rs and I think we're better off seeing if we can support the WASM target we need and solve this more generally.