A user hit an issue on an iPhone 5s. Device transfer would fail because
their app group was missing the ProfileAvatars directory.
This directory is lazily created as a post-launch job at background QoS.
It's not too big of a deal and it'll be created on demand if necessary.
The 5s was probably CPU constrained enough to never have a chance to run
any background jobs.
The fix is to just have our recursive filesystem traversal ignore any
unknown directory errors. This is only used in a couple places and the
behavior makes sense in each place.
While setting up the test CurrentAppContect, we use OWSTemporaryDirectory which in turn
recursively references CurrentAppContext, which crashes.
Clearing temp directories on every activation is sufficient.
To avoid blocking launch, file protection is now updated async for most
moved files. Out of paranoia, the database files are also update
redundantly on a sync code path.
It's still critical that we update permissions recursively for two
reasons:
1. Updating a containing directories FileProtection does not affect
existing files in that directory.
2. Because we've changed the containers default file protection level
(from unspecified to NSFileProtectionComplete), some existing files
will have there file protection updated upon launching Signal 2.20.
It's not clear to me which files this affects, and I haven't found
any relevant documentation, but from observation, it seems to affect
any top-level files in the container. Regardless, we're now doing the
right thing: after launching 2.20, ensure all file permissions are
what we expect.
Also removed no-op file protection on legacy db files. They've already
been moved by the time this method runs in AppSetup.
// FREEBIE
