libprocessgroup: Do not remove uid cgroups directory

In some rare cases, race happens between 2 processes in the same uid.

1. Process A is dying
2. system_server calls RemoveProcessGroup() for A
3. Zygote forks Process B with the same uid of A
4. system_server calls MkdirAndChown(uid) for B
5. system_server calls MkdirAndChown(uid, pid) for B

As 2 & 4/5 belong to different threads, 2 might happens before or after
step 4/5, or even in the middle of 4/5. In such a case, 4 or 5 will
fail, leaving process B in wrong (Zygote) group.

The uid dir is only created when the corresponding apps have been
launched at least once. It's reasonable to assume one of them is going
to be launched again. Deleting and recreating the uid dir just slows
down applaunch.

Introducing a new lock in libprocessgroup can also solve the race issue.
But that will slow down the applaunch further.

Therefore, reusing the uid dir is an optimized way to solve the race.

Ignore-AOSP-First: Freezer is not a public feature yet

Bug: 192512069
Bug: 168907513
Test: Kill corresponding apps and check the uid cgroupfs dir
Merged-In: I2e91088f21f45e4eda6c709a4af65ace7e135801
Change-Id: I2e91088f21f45e4eda6c709a4af65ace7e135801

libprocessgroup/processgroup.cpp

@@ -146,12 +146,6 @@ static int RemoveProcessGroup(const char* cgroup, uid_t uid, int pid, unsigned i
         std::this_thread::sleep_for(5ms);
     }
 
-    // With the exception of boot or shutdown, system uid_ folders are always populated. Spinning
-    // here would needlessly delay most pid removals. Additionally, once empty a uid_ cgroup won't
-    // have processes hanging on it (we've already spun for all its pid_), so there's no need to
-    // spin anyway.
-    rmdir(uid_path.c_str());
-
     return ret;
 }