… downloaded

Co-authored-by: Marvin W <[email protected]>

…sync

Verify that work accounts are only added by device owners or profile
owners.

For instance, Microsoft Intune will create a work profile (moving itself
to the work profile in the process) before using the work account servce
to create a work account, so at that point it will already be profile
owner. Apps that are not the profile owner will subsequently not be able
to disable the work account authenticator or remove the work account.
The personal account would not have an owner and thus no application
could enable the work account provider there.

Nonfunctional attempt.

Otherwise response values cannot be written to our intent.

Installed packages are deleted after installation, but if installation
fails and never retried (for instance: one large package is downloaded
successfully, then a small package is downloaded unsuccessfully due to a
network error, then the user uninstalls the app because it doesn't
work), this can still lead to storage leaks from
downloaded-but-never-installed apps. We should use `cacheDir` instead:
it will allow the system and users to clear the cache themselves.

Allows downloading large applications

* reduces temporary storage usage
* speeds up installation by a little bit

Storage leaks can still happen if session commits have errors (for
instance, because the device was shutdown during installation), as those
sessions can still be reopened and retried according to docs. However,
we may expect all dangling sessions to be cleared after a certain
timespan in the magnitude of a day.

Auth files are now moved to `play-services-base-core` so they can be
accessed by other the workaccount module.

Purchasing before downloading seems to be necessary in at least some
cases for work profiles as well.

Support unexpected scenarios spotted in the wild on a best-effort basis:

* Enterprise policies with apps missing policy fields
* App not downloading due to not being purchased