GitLab

This patch fixes #6

So far, bridgestrap would bootstrap a new tor instance for each request.
That's both expensive and slow.  Roger suggested to use a single,
long-lived tor instance instead, and use the SETCONF controller command
to test a batch of bridges at once.  This patch makes that happen.

This fixes #3.

Thanks to Cecylia for questioning whether the cache lookup mechanism is
fast enough:
ecc6e048 (comment 2709958)

When bridgestrap tests several bridges in parallel, it spawns several go
routines.  When all these go routines access our cache simultaneously,
we're running into sync issues because more than one go routine is
reading from or writing to the cache.

This commit adds a locking mechanism to fix this issue, and a unit test
to demonstrate that the fix works.

Our cache will contain hundreds of bridges.  Testing all these bridges
again after bridgestrap quits for whatever reason is expensive.  This
patch makes bridgestrap write its cache to disk when it exists, and
read it from disk when it starts, so we don't have to re-build our cache
after a restart.

The new flag '-cache' specifies the path to our cache.

Parsing Tor's log file is ugly and error-prone.  It's cleaner to use
Tor's control port to figure out if a bridge bootstrapped correctly or
not.  The library bulb helps us accomplish this.

This gets us to 41.7% coverage.