Add support for WASM targets running in a custom runtime

[hculea]

Background

Currently, on WASM targets, the zxcvbn crate can only be used if the host environment is JavaScript, such that functions such as js_sys::new_0()::get_time() would be available through bindings generated by e.g. wasm-bindgen.

Rationale

Not all code compiled to WASM is run in a JavaScript runtime.

One example is the 1Password Go SDK, which uses Extism to communicate with a Wazero runtime, which does not have the JS bindings available.

For context, this project leverages a Rust core (wherezxcvbn is used to determine the password's strength, when creating or updating 1Password items) compiled to WASM. Calls to it are made from the Go host env.

In situations where these system functions are not available, placeholders for it have to be injected into the runtime by the host.

In the Go code, injecting such a function would look similar to:
https://github.com/1Password/onepassword-sdk-go/blob/main/internal/imported.go#L31-L38

Thought process

This PR addresses this issue by allowing the host environment to inject its own implementation for the now function. It requires the environment to export a unix_time_milliseconds_imported, returning the unix timestamp in milliseconds.

This change is fully backwards compatible, and it requires that the consumers of the crate explicitly opt in to provide this custom implementation by activating the custom_wasm_env feature. In the absence of this feature, calls to zxcvbn would panic.

How to test

Code review, to begin with, would be greatly appreciated.

For functional review, I have put together a test repository where the new behaviour can be validated.

See testing notes in the README: https://github.com/hculea/zxcvbn-test

Additional information

In the scope of this PR, I have also:

• removed the getrandom dependency from the wasm32 dependency tree, as it was not being used anywhere
• removed the #![forbid(unsafe_code)] linter, as injecting a custom function requires the execution of unsafe code

[hculea]

@shssoichiro please do let me know if there is anything that I can do to help move this forward! 😄

[shssoichiro]

Sorry, I missed this MR before. It looks like there's still some issues with the build though. Would you mind taking a look? Wasm isn't my specialty.

[hculea]

No worries @shssoichiro, thanks for reaching back! Can you please re-run the workflows? 😄

[shssoichiro]

Looks like a missing use statement this time

[AndyTitu]

Hey @shssoichiro, @hculea is out on PTO so I agreed to take this to the finish line. I reverted a change that I believed to have caused the build step fail this last time, so can you please re-run the jobs when possible? Thanks!

[AndyTitu]

Hey @shssoichiro! Kind bump on the above: can you please re-run the jobs when possible? Thanks!

[shssoichiro]

Just returned from vacation, so I'm looking at this again now.

[shssoichiro]

Seems to still be having some issues, unfortunately.

[shssoichiro]

Thanks!

[hculea]

Thank you for the help here @shssoichiro!

Is there a process that we could kick off to create a new tag? We'd like to already leverage this functionality in our codebase