Fix updated privileged app with shared UID loses privileged permission

when request in manifest.

If two privileged apps share the same UID, one of them requested and
got a privileged permission granted while another didn't, both will be
granted the privileged permission. However when an update is installed
for the factory version of the system app that didn't request the
permission, and that updated app starts to request the privileged
permission, that request itself can't grant the permission because we
don't allow updated system apps to get new privileged permissions and
we only trust the factory version. However, the original permission
request from the other factory app is still valid. As a result of
this, in the refactored logic in S the permission has a chance to stop
being granted to both apps depending on the order of the two apps
being examined for permission grants.

The proper fix to this issue is to reconcile permission not by
packages, but by UIDs. However, given where we are in the S timeline,
such change will require a lot of refactoring to this critical piece
of logic, and may lead to performance regression even if it's okay
security-wise. So we should defer the proper refactoring to the next
release, either in this existing implementation, or in a new
permission subsystem.

The pre-S implementation had the logic that if a privileged permission
was granted to the factory version of a privileged app, it will
unconditionally keep the permission granted. And in the case of shared
UID, where the permission state of the factory app is the shared user
permission state, this helped resolving this issue. That piece of
logic was deemed unnecessary and simplified during S refactoring, but
this specific case shows that we actually still need it.

So we should bring back that logic in S. However due to the split of
permission and package locks, we can not call into package when we are
holding the permission lock. This is exactly the case in this piece of
logic because it needs both the disabled system package (guarded by
package lock), as well as the existing permission state (guarded by
permission lock). So we have to split the logic into two parts, that
is to store the information from package first, and then after
grabbing the permission lock, get the existing permissions state and
combine the two to reach a conclusion.

Another issue that existed before S was that the logic above was
broken by privapp permission allowlisting in O, which returns directly
without giving the logic handling updated system apps a chance to
run. So we need to fix this as well.

Test: Manual
Test: Install an updated system app that requests a privileged
      permission not in the allowlist but granted due to another
      shared UID app, and make sure that dumpsys package shows that
      the updated app has the permission both requested and granted
Fixes: 177926928
Change-Id: I667a9c2e1b87a15c22046e839b248ec6d4e55ca0