Properly handle stopping related users

Fixes UserController's mechanism for stopping users along with their
other profile group members, and improves what happens when exceeding
the maximum number of running users.

* The UsersLru will now always list profiles *before* their parent
  * This makes sense since parents must be "used" for the profile to run
  * This ensures that if we exceed maxRunningUsers, we'll stop profiles
    before their parents (i.e. priotize keeping full users alive)
  * This ensures that if we exceed maxRunningUsers, we'll count the
    number of users we plan on stopping correctly (i.e. no overkill)
* stopUsersLU, which stops a user as well as its "related users",
  formerly stopped a parent when called on its profile. This didn't make
  sense since stopping a profile shouldn't stop its parent. We change it
  to only stop a parent's profiles, not a profile's parent.
  This fixes the following bugs:
  * when exceeding maxRunningUsers, a user with profiles was much more
    likely to be killed, even if it was the main user
  * the stopProfile API would attempt to kill its parent too (!)
  * applying quiet mode to a profile of a background user would attempt
    to kill that background parent user too
* Adds more documentation explaining a bunch of this

Issues NOT tackled in this cl are:
* The system user's profiles are still not stopped when maxRunningUsers
  is exceeded
* When exceeding maxRunningUsers, we still don't prioritize keeping
  difficult-to-restart profiles (with separate challenges) alive
* The entire notion of "force==true" is left alone, even though it
  doesn't make much sense

Test: atest UserControllerTest#testRunningUsersListOrder_parentAfterProfile,testRunningUsersListOrder_currentAtEnd,testStopProfile_doesNotStopItsParent
Test: atest UserControllerTest

Bug: 324647580
Bug: 310249114
Change-Id: Ie08342bb77544117cab4423b543af74cbeb109e2

0 files changed, 0 insertions, 0 deletions