This is preparation for moving the threadClient to a front. Fronts do not support the
callback style that clients have, they only support promises. As such, this patch migrates all
instances of the threadClient using callback style methods to promises. I have cc'd the debugger
team so that they are aware of this change and it doesn't take them by surprise.

try run : https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=242251058&revision=dbd6cca9619ca0880e920d5b86fc6d6e0c728113

https://hg.mozilla.org/mozilla-central/rev/92678c01ead7

This is the first part of the threadClient refactor. It only moves the methods to the new
front. and does some basic fixes.

This is part one of removing threadClient specifics out of the debuggerClient. We were
managing messages from the thread client in a special way -- this was the "Unsolicited Pauses"
object that we had before. This patch updates the threadClient to use Front style events. This
required updating the spec for the threadClient, and several of the methods. What has not been fully
migrated here is the "resumed" event, as this is much more complex. This is taken care of in the
next patch.

The resume case is much more complex than the other events, because we do an
unsafeSynchronize to send an unsolicited pause. In the old system, the resume response would have
been ignored, but that is no longer the case. With the new system, we do not want to send a response
to a resume action if it did not come from the UI. This also update the debugger panel code to
accept a resume.

In order for a front to be available to getFront on a given target, it must be first --
registered on the target scope, and second -- set on the target's targetForm. This makes that update
for both browsing context and worker targets. This works as part of a work around until we can get
the server into better shape.

The webConsoleFront and the threadClient front both used to depend on the debugger-client
to destroy them via registered clients. This is no longer the case, and this code can be deleted

The front destroy method is async, but this is not respected if the client suddenly
disconnects. This causes issues with tests. This change introduces a mechanism for waiting on asyn
fronts to close.

This was a difficult situation. We are not waiting for a server response when setting or
removing breakpoints. The result is that the server has not completed those actions by the time the
test closed, leaving setBreakpoint or removeBreakpoint requests hanging, causing a number of tests
to fail. In order to get around this, I made the panel action "SET_BREAKPOINT" and
"REMOVE_BREAKPOINT" aware of the server response. This involved rewriting the helper methods
clientSetBreakpoint and clientRemoveBreakpoint so that they no longer relied on the dispatch.

It was not possible to use the dispatches to wait, as they had no event exposed to the tests,
especially in cases when we triggered these requests via button presses.

There were a few miscellaneous situations in which the test would fail due to a hanging
request. These tests passed in the past because the old way of using the threadActor did not
identify which requests had been responded to.

this patch fixes a few tests that had miscellanous timeouts

the test browser_net_params_sorted may not have been functioning for some time. While
investigating this, I discovered that we were getting an empty array for actualKeys. Iterating
over this array returned immediately. As a result the test always passed, even though the shape of
the data changed. I updated this code so that it waits for the dom to be populated with the number
of keys expected. I also updated the test to reflect the data the front end has today.

There was an issue where this test was timing out, and due to the way it was written it was
very hard to identify where -- there were many nested promises. I rewrote the test in order to
identify the time out.

this test was failing because the threadClient was posting messages due to being unable to
find the source map. After investigating, I found that the sourcemap was formatted incorrectly. I do
not know if this was intentional. If it wasn't this fix works. If it was, then we need to find a way
to wait on source map failures, and the test name might need to be updated

This test was failing due to the tab closing before a response from the tab was recieved.
It is due to the threadClient closing more quickly. This waits for the last message before closing

this test was failing because it did not wait for the debugger to finish reloading.

we shouldn't have this code, but we do

Alternative fix here is to only update telemetry after the response. I do not know if there
was a product decision here.

this is the weird one. we have a Debugger.executeSoon call for the destruction of the host.
However, before this happened immediately after the test closed. Now, it happens a little later, and
this messes up the data set up. The comment says that we cannot remove this.

The ChromeDebuggerActor extends the methods from threadActor but didn't have an event
emitter. I updated it to function the same as other actors

make sure we have a copy of thread client for old servers

Introduce a flag to maintain backwards compatibility with old servers

https://hg.mozilla.org/mozilla-central/rev/c5408cf27728
https://hg.mozilla.org/mozilla-central/rev/b77955eb4a71
https://hg.mozilla.org/mozilla-central/rev/3a9e09d5a4d7
https://hg.mozilla.org/mozilla-central/rev/3c5a0b786ffb
https://hg.mozilla.org/mozilla-central/rev/986402a59722
https://hg.mozilla.org/mozilla-central/rev/d2b8576bf67c
https://hg.mozilla.org/mozilla-central/rev/818e2521980c

Backed out for dt failures

Backout link: https://hg.mozilla.org/integration/autoland/rev/97d91e58ce25a28bbfe95128b2a8a542c6fe8e20
Push link: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Crunnable&selectedJob=251819678&revision=5db908b26d508d9369153131e969bd665028d4d9
Log link1: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=251819931&repo=autoland&lineNumber=5207
Log link2: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=251823135&repo=autoland&lineNumber=1547
Log link3: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=251819928&repo=autoland&lineNumber=2196

https://hg.mozilla.org/mozilla-central/rev/5ea8582b48c0
https://hg.mozilla.org/mozilla-central/rev/9d24fd51deb4
https://hg.mozilla.org/mozilla-central/rev/eacdf422f586
https://hg.mozilla.org/mozilla-central/rev/2a4f4639567a
https://hg.mozilla.org/mozilla-central/rev/3c1c8393c6e8
https://hg.mozilla.org/mozilla-central/rev/9732099eeb56
https://hg.mozilla.org/mozilla-central/rev/2494fafdeae7
https://hg.mozilla.org/mozilla-central/rev/1d3845e33eb9
https://hg.mozilla.org/mozilla-central/rev/01195404b5ea
https://hg.mozilla.org/mozilla-central/rev/caefc0b61c81
https://hg.mozilla.org/mozilla-central/rev/7408af62d6bb
https://hg.mozilla.org/mozilla-central/rev/0013565e760d
https://hg.mozilla.org/mozilla-central/rev/67445d8e4d05
https://hg.mozilla.org/mozilla-central/rev/ec5d586ced75

Comment on attachment 9069357 [details]
Bug 1494796 - update chromeDebugger to use event emitter

Revision D33498 was moved to bug 1239008. Setting attachment 9069357 [details] to obsolete.

Comment on attachment 9068068 [details]
Bug 1494796 - rename context to thread; r=jdescottes

Revision D32849 was moved to bug 1559819. Setting attachment 9068068 [details] to obsolete.