fix(linux): remove harmful request loading workaround

[dgerhardt]

With the introduction of the multi webview unstable feature in #359, a workaround for request loading during webview initialization was added for an unknown concurrency bug in WebKitGTK. This PR now removes it because it has negative side effects and does not seem to be needed anymore:

• it introduces a deadlock situation (partially mitigated by fix(linux): deadlock in WebViewUriLoader #1561),
• it disables parallel loading when initializing multiple webviews, and
• the bug can no longer be reproduced using current WebKitGTK versions.

The workaround does not seem to have ever been intended to be a long term solution (FIXME comment). Unfortunately, there is no issue linked for the underlying issue and no reproduction was provided, which makes it hard to tell if the bug still exists with newer versions of WebKitGTK. But I have not been able to reproduce the issue on Ubuntu 24.04 using libwebkit2gtk-4.1-0@2.48.3-0ubuntu0.24.04.1. In the worst case scenario, this would cause a regression on an unstable feature while still fixing and improving webview loading in general on Linux.

This PR provides an alternate solution for #1562, which instead introduces a feature flag to opt out of the workaround.

Original description of the workaround:

Prevents an unknown concurrency bug with loading multiple URIs at the same time on webkit2gtk.

Using the queue prevents data race issues with loading uris for multiple [WebView]s in the
same context at the same time. Occasionally, the one of the [WebView]s will be clobbered
and it's content will be injected into a different [WebView].

Example of webview-c clobbering webview-b while webview-a is okay:

webview-a triggers load-change::started
URISchemeRequestCallback triggered with webview-a
webview-a triggers load-change::committed
webview-a triggers load-change::finished
webview-b triggers load-change::started
webview-c triggers load-change::started
URISchemeRequestCallback triggered with webview-c
URISchemeRequestCallback triggered with webview-c
webview-c triggers load-change::committed
webview-c triggers load-change::finished

In that example, webview-a will load fine. webview-b will remain empty as the uri was
never loaded. webview-c will contain the content of both webview-b and webview-c
because it was triggered twice even through only started once. The content injected will not
be sequential, and often is interjected in the middle of one of the other contents.

FIXME: We think this may be an underlying concurrency bug in webkit2gtk as the usual ways of
fixing threading issues are not working. Ideally, the locks are not needed if we can understand
the true cause of the bug.

Closes tauri-apps/tauri#12589
Refs #359

[github-actions]

Package Changes Through 12a48ee

There are 1 changes which include wry with patch

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
wry	0.53.2	0.53.3

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[lucasfernog]

looks like it still works, let's see if something comes up.

@chippers please let us know if you still can reproduce the bug or if you have a reproduction example out there still :D

[chippers]

looks like it still works, let's see if something comes up.

@chippers please let us know if you still can reproduce the bug or if you have a reproduction example out there still :D

i think i have a video of it, because i remember making a video of my test case opening dozens of windows in a tiling manner on my 4k monitor to try and reproduce it (only sometimes), but it's been so long idk where it is or the test suite i made for it. if i find it ill post it but if it's no longer needed, that's good :)