Reduce lock interactions in backup transport management

1. process package update broadcasts on our background thread rather
   than on the main looper thread

2. don't synchronize unnecessarily around access to simple
   transport metadata

We mustn't block the main looper thread for anything that might wind
up interlocked with calls to the transport, because those might take
arbitrary amounts of time.  We were previously entering such an
implicitly interlocked code path during package-changed broadcast
handling, and in pathological cases were causing the watchdog to
restart the system.  This situation is addressed in a couple of ways:
first, by no longer performing package-update work on the main looper
thread at all; and second, by eliminating lock reliance entirely from
data-access paths that don't actually need it.

Bug: 65438129
Bug: 64133971
Test: manual + CTS
Change-Id: I361ad4a0729f319db7339bd341a6d33aa3b64fed