feat(cat-voices): implement web worker for compression logic

[apskhem]

Description

Moved the compression functions in JS side to run in web workers to prevent blocking (freezing) on the main thread that might impact on user experiece during using the app.

Related Issue(s)

Closes #1014

Description of Changes

• Added web worker support to compression functions.
• Changed all the functions that rely on the interop functions to run with async manner.

Breaking Changes

TD;LR: Compression functions in JS return Promise<string> instead of string.

The compression functions in JS was changed to run in web workers. Hence, all the functions return Promise<string instead of the old version of returning solely string. The interop functions in the Dart side (catalyst_compression_web) also need to change accordingly to support those JS functions. So the packages or functions that rely on this compression package need to convert themselves to run asynchronously.

Please confirm the following checks

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream module

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 294/294}$ | ${\color{red}Fail: 0/294}$ |

[apskhem]

@minikin @dtscalac This change affacts several packages inside catalyst_voices_packages. Should we also update the version of the packages?
And also in catalyst_compresion_web, there's still a fixed path to load web worker from here. It fits only for catalyst_voices at the moment. Should we parameterize the path?

Edit: the fixed path problem is indentified by loading from its relative path.

[dtscalac]

@minikin Objectively speaking this PR reduces the lag however it still happens. I've debugged the issue and the biggest offender once the compression was optimized is the Ed25519 signing which takes about 180ms per signing, we do it twice per registration.

@apskhem can you please report another task for this? Here's the part of code that is slow:

[apskhem]

I created a new ticket related to @dtscalac inspecting on the issue (#1025)

[dtscalac]

LGTM