WASM IO compat

[CPerezz]

In this crate, we rely on functions that require reading .r1cs and .wasm files from the user's computer in order to be able to generate folding circuits.

The problem is that when we try to use sonobe in wasm (particularly in the browser) this crate only knows 1 way to get served this two files and it's though file paths that will then be read.

So an alternative is needed that is compatible with in-browser file reading.

One good example is how is done in Nova-Scotia. But with this, we are only able to fetch stuff from a website.

This can be a low-hanging-fruit to enable a very minimal browser-compat. We should later evaluate if we should also try to go for other alternatives like using FileReader from MDN web-docs which is available in toolkits like gloo. Specifically, gloo-file.

A final option is to use Web Storage API which should allow us to let the developers of apps load the file with JS or whatever it is, and then to provide a key with which this data was stored with and let us query it from Rust obtaining the file contents which we can then pass to sonobe to do it's work.

IMO, we should go for the Nova-Scotia approach. Which is simple and easy to implement without trouble. And later, we can figure out if we need to improve this or not.

[CPerezz]

I went so far for the easiest approach. Which is simply to allow to pass bytes directly into the CircomWrapper object such that JS can handle the read on whatever way is wanted.

The only main issue, is that even it is implemented, the WitnessCalculator struct can only be created from Path.

    pub fn new(path: impl AsRef<std::path::Path>) -> Result<Self> {
        Self::from_file(path)
    }

See the constructors avaliable here

It's sad because indeed, wasmer supports this creation from binary. See this.
I ignore if there's any reason to not support this. So I've filed arkworks-rs/circom-compat#72 to see if all this makes sense or instead, there's another way to go that I just don't see.

For now, this will get slightly stuck. I'll try to PR to both circom-compat upstream and our forked dependency which we're patching. And on that way, we might be able to get it much faster.

[arnaucube]

Thank you very much for delving into this! 🙌
Yes, I think that it makes sense to move forward with updating our fork of circom-compat to add this feature, since it already contains updates (eg. abstracting the field over which the lib works (the original repo only works over BN254's Fr field), and also updates the way how public inputs are handled to be able to specify public inputs so that we can use it as frontend for the IVC).
Once we have all this working and stable, we can prepare a PR to circom-compat's upstream, since probably will benefit other users of the library all the changes that we're making, but at least in this way we can move forward and use the lib in the browser already ^^

[CPerezz]

#149 definitely fixed this.

I think we can close the issue and revisit it in the future if further improved support is required.