Disable chromoting service on permanent errors.

Stop the daemon process from repeatedly starting up and shutting down the network process when the host has been unregistered.

We have two bugs in the chromoting host that caused the repeated startup and shutdown of the network process when the host has be unregistered:
1. The host process never exits naturally. As a result, the WorkerProcessLauncher in the daemon process never receives the exit code and thus isn't aware that a "permanent" error occured.
2. If a host has service account enabled, it gets kInvalidOauthCredentialsExitCode instead of kInvalidHostIdExitCode if the host has been unregistered in the service directory. But we only disable the service upon the latter.

Issue 1 is a regression from https://codereview.chromium.org/891663005 which added a dangling reference to the UrlRequestContextGetterin HostProcessMain. This leaked object will also keep the Network task runner, and thus the UI task runner alive. So the message loop in HostProcessMain never quits.

I created crbug.com/475213 to track the original DCHECK.

BUG=472884
Committed: https://crrev.com/82a08f2840b6fdab51581818b4bbec07719541e3
Cr-Commit-Position: refs/heads/master@{#324377}

[weitao, 2015-04-07 19:05:07]

weitaosu@chromium.org changed reviewers:
+ sergeyu@chromium.org

[weitao, 2015-04-07 19:05:59]

Sergey PTAL.
Note that the CL is not complete yet. I still need to fix the unit tests. But I
want to get your feedback before working on that.

[Sergey Ulanov, 2015-04-07 21:31:51]

What's the reason we need ChromotingNetworkDaemonMsg_HostShutdown? Can it be
removed?

We have two different mechanisms that the network process can use indicate to
the daemon that it's finished and I don't see any good reason for that.

[Sergey Ulanov, 2015-04-07 21:50:18]

Looking at the code once again I think ChromotingNetworkDaemonMsg_HostShutdown
may be useful, but I do not understand how it causes the race

https://codereview.chromium.org/1061903002/diff/20001/remoting/host/daemon_pr...
File remoting/host/daemon_process.cc (right):

https://codereview.chromium.org/1061903002/diff/20001/remoting/host/daemon_pr...
remoting/host/daemon_process.cc:369: void DaemonProcess::OnHostShutdown(int
exit_code) {
It looks like ChromotingNetworkDaemonMsg_HostShutdown is there to indicate to
HostStatusObservers in the daemon process that the host is offline. It doesn't
mean that the network process is dying - the host may be restarted again in the
same network process. So I don't think right to add exit_code here. How does the
network process get killed in response to this message?

https://codereview.chromium.org/1061903002/diff/20001/remoting/host/daemon_pr...
File remoting/host/daemon_process_win.cc (right):

https://codereview.chromium.org/1061903002/diff/20001/remoting/host/daemon_pr...
remoting/host/daemon_process_win.cc:153: // the host is no longer able to
authenticate.
This description is too wordy. I don't think you need that many details here.
e.g. it's not necessary to mention service accounts. There are 2 types of
"permanent" errors:
 1. Errors that may go away without changes to the host config. This happens
mainly when the host fails to start due to policies, e.g.
kInvalidHostDomainExitCode.
 2. Errors that will never go away with the current config.

kInvalidHostIdExitCode and kInvalidOauthCredentialsExitCode are in the second
category. For such errors we want the service to be disabled. It's assumed that
the service will be re-enabled whenever the config is updated.

https://codereview.chromium.org/1061903002/diff/20001/remoting/host/host_exit...
File remoting/host/host_exit_codes.h (right):

https://codereview.chromium.org/1061903002/diff/20001/remoting/host/host_exit...
remoting/host/host_exit_codes.h:21: kPolicyReadError = 4,
These are not exit codes. When host can't read policies it keeps running trying
to read policies.

[weitao, 2015-04-08 21:21:34]

PTAL.

[Sergey Ulanov, 2015-04-09 01:06:53]

lgtm

[weitao, 2015-04-09 03:49:11]

The CQ bit was checked by weitaosu@chromium.org

[commit-bot: I haz the power, 2015-04-09 03:50:57]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1061903002/60001

[commit-bot: I haz the power, 2015-04-09 04:50:17]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-04-09 04:52:11]

Patchset 4 (id:??) landed as
https://crrev.com/82a08f2840b6fdab51581818b4bbec07719541e3
Cr-Commit-Position: refs/heads/master@{#324377}