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.

Only the bundle contents created by Briar classes are encrypted.

This limit is necessary to limit the size of subscription update
packets; it can be lifted when incremental subscription updates are
implemented.