This code was only used for workers targets, which weren't passing breakpoints
from the server side via "sessionData" concept.
Instead, we were still relying on the frontend to pass them and only after that
manually requesting the thread to resume its execution.
Now, there is still a notion of "attach" around the thread actor.
While all the targets are immediately instantiating their related thread actor,
the thread actor isn't active by default.
It becomes active as soon as:
* SOURCE or THREAD_STATE resource is watched
* breakpoints are set via session data (breakpoint list actor)
* thread configuration are set via session data (thread configuration actor)
I had to do one of these things in order to keep test from working.
In the production code, we do most of these things by default on the toolbox startup.
We could revise this behavior by:
* always attaching the thread actor, but it may start pausing unexpectedly in some tests.
* decouple sources from breakpoints within the thread actor, so that watching for sources doesn't necessarily "attach" the thread actor and activate breakpoints/debugger statements.
* have a new thread configuration to explicitly enable the thread actor pausing features.
I'm often using thread configuration to enable pausing in tests.
This required to improve xpcshell test helpers to be able to use Watcher/Commands.
About browser_target_command_bfcache.js, the DevTools code is now so quick that the
back/forward requests at done too quickly one after the other and fail actually moving to
the other document.
Differential Revision: https://phabricator.services.mozilla.com/D166321
87250d4e53