Figure out deployment strategy for obfs4

While we were busy doing other things, Yawning created his own PT which supercedes scramblesuit. obfs4 (this is a temporary name), aims to have all the features of scramblesuit and a bit more (for example, it has better performance because of Elligator instead of UniformDH).

The code can be found at https://github.com/Yawning/obfs4 and apparently it already has feature parity with scramblesuit.

We should decide whether we should deploy obfs4 and when.

Some possible avenues:

• Deploy both scramblesuit and obfs4. This is a bit pointless since obfs4 does not have any real threat model differences over scramblesuit. And deploying another transport means that we have to ask bridge operators to upgrade, and users to learn another transport name (crying wolf paradigm applies here too). Also, maintaining two similar codebases is a bit stupid.

• Deploy obfs4 instead of scramblesuit. This makes more sense since obfs4 is supposedly strictly better than scramblesuit. However:

  1. scramblesuit is already a bit deployed. We have a few bridges already running it, and it was also recently added in the TBB https://gitweb.torproject.org/builders/tor-browser-bundle.git/commitdiff/ef80bcdfd15ba873de6c7a88382176b893770638.
  2. obfs4 is untested and will probably need some time to pass quality control and review.
  3. obfs4 is a go application, so it needs an extra patch to the TBB build process.

• Continue scramblesuit deployment, and hold on to obfs4. Maybe we can use obfs4 as an emergency transport in the future. Unfortunately, this is suboptimal. since it means that we will have to write TBB build patches to deploy the emergency transport. It would make more sense to hold on scramblesuit as the emergency transport (since it's already in obfsproxy).