[Web] Fix dlopen threading issues by pre-opening all GDExtensions

[Faless]

Calling dlopen from a thread cause stalling on some browsers (notably firefox: #86382), the only valid workaround seems to be to dlopen all GDExtensions from the main thread as soon as possible.
We then keep track of the pre-opened libraries, and return the correct stored when a thread try to dlopen.

This means still no editor+thread+dlink support yet (since we don't know which libraries to open at startup in that case).

Draft status:

• Requires way more hacks than I'd like (having 3 main functions, 4 callbacks, and a fake loop is not great :/ )
• Only tested in 4.2 yet (via https://github.com/Faless/godot/tree/web/4.2_fix_dlopen_by_preloading)

[adamscott]

Instead of using "fake" and "real" terminology, why not instead use "phase1" and "phase2"? Phase 1 loads phase 2, so we would have phase1_loop() (with a comment // Does nothing.), and a phase2_loop.

[dsnopek]

As a workaround, this seems fine.

It would be nice if we could make OS::open_dynamic_library() asynchronous, so that its work could be deferred to the main thread. Since it's internal and not exposed to users, that's theoretically possible, but since exposed APIs that depend on it (like GDExtensionManager::load_extension()) are synchronous, I don't think we could easily do that. I suppose we could add a LOAD_STATUS_DEFERRED along with a signal to GDExtensionManager? But that's not something we should really try to do for Godot 4.3.

[dsnopek]

Is this one superseded by PR #93143 now?

[adamscott]

Is this one superseded by PR #93143 now?

By the look of it, yes, it seems so.

[Faless]

Is this one superseded by PR #93143 now?

Yes it is, closing.