Thread-safety & Locking
I encountered a race condition while running wormhole receive where one thread called spake2.spake2.SPAKE2_Symmetric.finish() before spake2.spake2.SPAKE2_Symmetric.start() was complete. Now I'm having trouble recreating it in wormhole (of course :smile: ), but easy enough fix: this PR adds locking to the start and finish methods of _SPAKE2_Base. It also upgrades the included version of six to 1.11.0 because there was also a thread-safety bug in six<=1.9.0.
Changes Unknown when pulling 84c7d5c8f2e9fb8d96660c20b58416a56b9640ff on jtdoepke:locking into ** on warner:master**.
warner/magic-wormhole#280 sounds like it addressed the same bug, so I guess this PR is no longer necessary.
If there is (still) interest in this, please re-open without the "six" changes.
For threaded users, it might be nicer overall to have a "locked" version, so that async or other single-threaded users don't pay any penalty for the lock. (Looking quickly at the referenced magic-wormhole fix it seems the real culprit was "using Twisted APIs wrong" and not necessarily a lock issue here?)