Do not disable IMEs upon force-stop

This is a follow up to my previous CL [1], which aimed to fix
Bug 27859687 without changing any other behavior but
unintentionally changed the observable behavior when a currently
enabled IME is force-stopped.

What would happen when a currently enabled IME is force-stopped has
never been protected with any end-to-end test, but here is a brief
history.

 - Feb 22, 2010 [2]

It is also when Dianne introduced PackageMonitor class. At that time
InputMethodSettings will be updated in the following order upon
force-stopping an IME package.

 1. if selected then unselect it then reset it to the most appricable
    IME.
 2. if enabled then disable it.

This behavior was, however, not super obvious because at that time
IMMS did not verify whether the currently selected IME is enabled or
not when selecting it. This means that IMMS continues using the
force-stopped IME as long as it remains to be the currently selected
IME at the step 1.

Note that IMMS did not support multi-user at that time. Thus no
semantics was defined about what would happen when an enabled IME was
force-stopped for a background user.

 - Sep 26, 2012 [3]

The initial multi-user support was introduced for IMMS. At that time
the observable behavior is that IMMS did nothing when an enabled IME
for a background user was force-stopped.

 * Current user
   1. if selected then unselect it then reset it to the most
      appricable IME.
   2. if enabled then disable it.
 * Background users
   1. do nothing.

 - Feb 17, 2016 [4]

While working on direct-boot support in IMMS, I introduced a new logic
to make sure that at least one non-auxiliary IME is enabled. This
slightly changed the force-stopping scenario as follows.

 * Current user
   1. if selected then unselect it then reset it to the most
      appricable IME.
   2. if enabled then disable it.
   3. make sure at least one non-auxiliary IME is enabled.
 * Background users
   1. do nothing.

 - Feb 22, 2017 [5]

At that time when I introduced an optimization around

  InputMethodManagerService.MyPackageMonitor

there was an unintentional behavior change. As a result enabled IMEs
would no longer be temporarily removed from the enabled IME list. The
root cause was that I forgot to update

  MyPackageMonitor#mChangedPackages

in

  MyPackageMonitor#onHandleForceStop().

This unexpected behavior change has, however, never been noticed. The
force-stopping behavior had changed as follows.

  * Current user
    1. if selected then unselect it then reset it to the most
       appricable IME.
  * Background users
    1. do nothing.

 - Feb 09, 2023 [6]

At that time we finally addressed an issue where the current IME could
switch to any IME, even if it was not enabled. This change itself did
not change any observable behavior around force-stop because of my
previous CL [4].

 - Feb 29, 2024 [1]

With my CL, the behavior became an mixture of above ones, that is,
IMMS disables the currently selected IME and IMMS refuses to continue
using the selected IME that is not enabled any more.

 * Current user
   1. if selected then unselect it then reset it to the most
      appricable IME.
   2. if enabled then disable it.
 * Background users
   1. do nothing.

This is how Bug 333798837 became noticeable.

 - This CL

With this CL, we actually switch back to the one revision prior
behavior where IMMS does not remove force-stopped IME from the enabled
IME list.

  * Current user
    1. if selected then unselect it then reset it to the most
       appricable IME.
  * Background users
    1. do nothing.

Rationals are:

 - That's what we have been using since Android O. We don't want to
   introduce any drastic observable behavior change unless it's
   necessary.
 - That's also what we have been using for any background user.

We also finally introduce end-to-end tests [7].

 [1]: I10aa547f0de607ef3c0ba26764dac0585c40c843
      2501e749
 [2]: 21f1bd17
 [3]: Ib23849d352db33f0747aa9d5a178f00ac726c13b
      4e1ab15b
 [4]: Ibd53ef8db7afcfac681b401912876d2a52c743d5
      859df05c
 [5]: I063688297156188f68fe0b55a46d72f2e811dc88
      5e3e8a52
 [6]: I12829de9fa58610a7d53e4b154e1550f0f791e75
      55f6a873
 [7]: If7dd75a23310acc82a9ed2acf169d4c3b7ca47b7

Bug: 322062773
Fix: 333798837
Test: atest CtsInputMethodInstallTestCases:ForceStopTest
Change-Id: I261e1c60050ee20f7673425f75588269f865ba50