Warning: This build has drifted.
The coverage report for this pull request build may be inaccurate because its base commit is no longer the HEAD of its target branch.
This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

    • Learn more: For more information on this, see Tracking coverage changes for pull request builds.
    • Fix now: For a quick fix, rebase this PR at GitHub. Your next report should be accurate.
    • Prevent going forward: To avoid this issue with future PRs, see these Recommended CI Configurations.

fix: prevent deadlock when calling blocking methods inside event handlers

Event handlers run synchronously on the single connection dispatch
goroutine (connection.Dispatch -> channel.Emit). That goroutine is also
the only one that delivers replies which unblock channel.Send. So any
blocking server call made from inside an event handler -- e.g.
Response.Body(), Request/Response.HeadersArray()/AllHeaders(), or
Page.EvaluateHandle() from an OnResponse/OnRequest/OnRequestFinished/
OnDOMContentLoaded callback -- waits forever for a reply that can only
be delivered by the goroutine it is blocking. Route handlers avoid this
because they already run on a separate goroutine via channel.CreateTask;
plain event handlers do not.

Fix: when waitResult is invoked on the dispatch goroutine itself (i.e.
from within a handler), it now drives the receive loop re-entrantly via
pollOnce until the reply arrives, instead of blocking on a channel only
the dispatch goroutine could signal. Calls from any other goroutine are
unchanged. Keeping all message processing on a single goroutine
preserves the existing event ordering and avoids data races on the
object graph.

Adds TestBlockingServerCallInsideEventHandler covering the cluster.

Closes #391
Closes #481
Closes #398
Closes #574