Previously, when table A had a foreign key pointing to table B, we got
read locks on A and B to read A, a write lock on A and a read lock on
B to update A, and a write lock on B to update B (but this wasn't
applied consistently). Now we get a read lock on A to read A, a write
lock on A to update A, and write locks on A and B to update B. The
difference is small in practice, but clarifying the rules has helped to
catch some bugs.

Perhaps a better solution would be to make all components restartable,
but that's difficult as they may have entered error states.

It would be nice to be able to put this code in a superclass, since in
the case of an activity like this it only deals with superclass state.

Mutable static fields should be avoided, but this is the only way to
make the bundle encrypter available before calling
RoboActivity.onCreate(), which needs to be passed the decrypted state.

Only the bundle contents created by Briar classes are encrypted.