Fix race condition when closing redundant Bluetooth sockets
The Bluetooth invitation code has a race condition: if Alice and Bob connect to each other at roughly the same time, they each consider their outgoing socket to be redundant and close it, resulting in both sockets being closed. This can be triggered pretty reliably by using two phones of the same model and pressing 'Continue' at the same time on both phones.
When more than one invitation socket is opened, Alice should pick which one to use and Bob should use whichever one Alice picks, which Bob can detect by trying to read from both sockets.
Hopefully the Bluetooth invitation code will be retired when #117 is merged, but I'm putting this up for review in case we need to keep Bluetooth as a fallback method.
See merge request !120
When more than one invitation socket is opened, Alice should pick which one to use and Bob should use whichever one Alice picks. This fixes a race condition where each party picked a different socket and closed the other.
1. The things we're really trying to protect - contact identities,
message contents, etc - can't be erased from memory because they're
encapsulated inside objects we don't control.
2. Long-term secrets can't be protected by erasing them from memory
because they're stored in the database and the database key has to be
held in memory whenever the app's running.
3. If the runtime uses a compacting garbage collector then we have no
way to ensure an object is erased from memory.
4. Trying to erase secrets from memory makes the code more complex.
Conclusion: Let's not try to protect secrets from an attacker who can
read arbitrary memory locations.
