Before registering a driver we queue the requests and send them to driver once it registers itself. So I don't think connecting to IMEServer before driver registers is a problem.

The problem is we started test_ime_driver twice: Once in IMEServerImpl, and a 2nd time in InputMethodMusTest. If a client connects before the 2nd start, then the 2nd start will kill the connection between the client and the 1st driver, so the client will indefinitely wait for a response if it doesn't handle connection errors.

I'll submit a CL to fix this shortly.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c2edfc8753717dee68567dbb08f04e8623f1be65

commit c2edfc8753717dee68567dbb08f04e8623f1be65
Author: moshayedi <moshayedi@chromium.org>
Date: Wed Nov 30 16:45:01 2016

IME for Mus: Fix InputMethodMusTest.DispatchKeyEvent's deadlock.

What was happening was:
 - IMEServerImpl starts test_ime_driver, which registers itself to Mus.
 - InputMethodMusTests requests to start test_ime_driver, but before it
   starts, it connects to IMEServer, which creates a connection between
   client and the first test_ime_driver.
 - test_ime_driver starts for a 2nd time, which causes IMEServerImpl to
   drop the connection to the first test_ime_driver. This causes
   clients using the first test_ime_driver to hang.

This fix:
 - Removes starting the test_ime_driver for a 2nd time.
 - Rejects drivers after first driver registers itself.

BUG= 668181 

Review-Url: https://codereview.chromium.org/2535403002
Cr-Commit-Position: refs/heads/master@{#435291}

[modify] https://crrev.com/c2edfc8753717dee68567dbb08f04e8623f1be65/services/ui/ime/ime_server_impl.cc
[modify] https://crrev.com/c2edfc8753717dee68567dbb08f04e8623f1be65/ui/views/mus/input_method_mus_unittest.cc