Replace questionable resetCurrentMethodAndClientLocked()

This is a preparation to start maintaining
InputMethodBindingController instance for each user.

If you take a closer look at what

  InputMethodMangerService#switchUserOnHandlerLocked(),

then you may find that we update IMMS#mCurrentUserId to the new user
ID first, followed by IMMS#resetCurrentMethodAndClientLocked(), which
resets the state for the new user. In reality, however, what we have
cleaned up are states in IMMS for the previous user. Such confusions
are not new at all. I can actually see them at least 6 years ago [1].

Another relatively new confusion is around

  InputMethodManagerService#onUnbindCurrentMethodByReset() [2]

which was introduced to address Bug 285821212.

The code in question is now invoked not only when the IME user is
switching but also when resetCurrentMethodAndClientLocked() gets
called for other reasons, while its code comment and manual testing
only mention the IME user switching scenario. Watch Bug 338461930
regarding whether such a workaround is still necessary or not.

Anyway with this CL

  InputMethodManagerService#switchUserOnHandlerLocked()

starts explicitly resetting state for the previous user rather than
the current user, with a TODO comment about Bug 197848765 where we are
going to see if we can keep the previous IME binding alive for better
profile switching performance.

We hope there is no observable behavior change, but if there was then
it'd be considered to be a bug that needed to be fixed sooner or
later.

 [1]: I63388402369f58d11fdb21b508eb2051ff39fa5b
      0d7aff8ab22b25e4215bee1a1f1da830a4d8fbfe
 [2]: I0873ec065722e9e0b22dd5010d3415d3704cfd2d
      56fa64663f909bf79367c3c2122737a6c7a8c0d1

Bug: 325515685
Test: presubmit
Change-Id: Ida3cb689b450a775529edebb87cbb6e58b32c8a6

0 files changed, 0 insertions, 0 deletions