UnmeasuredPercentileRestriction is a little slow if there are a lot of nodes...

Man, what happened here? I pointed out most of these issues in code review...
https://trac.torproject.org/projects/tor/ticket/6131

Torflow expects the PURPOSE to not be None but "" if no PURPOSE is set.

In torspec.git commit e195a4c8d288eb27385060740b8fde170a5e3e38 the
format of the CIRC event was changed slightly. This commit parses this
newer format.

Routers with the Unmeasured flag get a hard-coded consensus to descriptor
ratio of 1.0

Should eliminate the keyerror in the test's node_map, which seemed to be due
to really stale last_exits laying around from previous tests on a different
consensus.

Added support for detached heads

see:
http://www.sqlalchemy.org/docs/orm/session.html#lifespan-of-a-contextual-session
  "This has the effect such that each web request starts fresh with a brand new
  session, and is the most definitive approach to closing out a request."

try to use the same session for deletes and queries where possible,
this may be the cause of an ObjectNotFound exception that occurs
right after _update_db(), despite the Router object being in the
consensus and also in the db.

suspicious session behavior may require refreshing all
objects in order to keep tc_session and sessions bound
to Elixir synchronized

Need to move it for that...

By fixing the miscount, of course.

SQLSupport.refresh_all() is required to keep Elixir and
tc_session in sync. Otherwise it is possible for
routers added by the consensus update to not show up
in queries using the Elixir model i.e. Router.query.all()

Also, warnings have been added to SQLSupport.reset_all() because
this does not work properly -- in some cases relation tables
were not being reset properly (this resulted in old bw measurements
being repeated in future output!).

Finally, even when reset_all() works properly, bwauthority memory
usage continues to grow.

calls parent and SQLSupport reset functions
Tests show that SQLSupport.reset_all() may clear too much because
if BwAuthority calls Scansupport.reset_stats() after each speedrace()
run only the first slice is properly recorded; the rest are empty.
See: https://trac.torproject.org/projects/tor/ticket/2947

Postgres doesn't ignore divide-by-zeros like MySQL
CASE statement added to set the result to NULL if
the denominator is zero

this actually appears to work