Prevent accidental re-initialization

[matheus23]

Motivation

Calling init, or other initialization functions twice accidentally can cause subtle bugs. It should check if it ever got initialized before and just return if it did.

Proposed Solution

In finalizeInit, perhaps a check like if (wasm != null) return wasm; as the first operation.

Alternatives

Well, personally I'd love to use wasm-bindgen generated modules similar to how they've been designed in the browser APIs: During initialization, you provide the imports and the initialization call gives you all exports. Imports and exports are tied to a specific wasm module instance.
However, I realize two things:

• The current design is so that you can import wasm-bindgen generated projects in nodejs as if they were a normal library, without having to initialize anything.
• It would be quite a breaking/effortful change to provide a different API, especially if eventually browsers just support ELM-style .wasm imports directly.

Additional Context

When we called init twice, the issue we got was actually really subtle and annoying to debug:
We used the weak refs feature, i.e. FinalizationRegistrys were generated for us.

So in the main wasm-bindgen-generated project.js file (we used wasm-pack build --target web) we have following code generated:

let wasm;

// ...

const PublicNodeFinalization = new FinalizationRegistry(ptr => wasm.__wbg_publicnode_free(ptr));

// ...

function finalizeInit(instance, module) {
    wasm = instance.exports;
    init.__wbindgen_wasm_module = module;
    cachedInt32Memory0 = null;
    cachedUint32Memory0 = null;
    cachedUint8Memory0 = null;


    return wasm;
}

Now, imagine you cause finalizeInit to run once, then the wasm variable will be set to some module.
In our code, we now continued running operations on our PublicNode. This causes them to be allocated and returned to JS and registered in their respective FinalizationRegistry.
Please note that the FinalizationRegistry closes over the wasm variable.
So now our code accidentally called finalizeInit again, which overwrites the last wasm value, and created a buch more PublicNodes.

When eventually enough PublicNodes were created, GC kicked in and deleted some older ones. These older ones then had their finalizers run and that caused the finalizers to be run on the "wrong" wasm memory. The ptr parameter wouldn't make sense in the new wasm instance.

Unfortunately that was really hard to debug, since finalizers only run when you've accumulated a bunch of garbage.
There's also other oddities like the error causing a "memory access out of bounds" (likely due to the ptr value being too big for the new wasm instance), but straight up causing a SIGBUS in nodejs on M1 Macs.