Flakey password verification test

[russjones]

----------------------------------------------------------------------
FAIL: password_test.go:98: PasswordSuite.TestTiming

password_test.go:163:
    c.Assert(diffFraction < 0.1, Equals, true, comment)
... obtained bool = false
... expected bool = true
... elapsed difference (11.278536047602582%) greater than 10%

[zmb3]

As I noted in a related PR:

The idea here is that if a user doesn't exist, then by default the call would complete faster since it doesn't have to do any comparison. We mitigate this by intentionally slowing down the "user doesn't exist" case by doing a comparison against a dummy hash instead. This way we aren't leaking any information to an attacker about what users may or may not exist in the backend.

The irony here is that the user doesn't exist case is actually slower than the case where the user does exist, and by slowing it down further we're only increasing the gap. We don't notice this because the test only looks at the absolute value of the delta.

suspect this is because the amount of time it takes to compare the password hash is dwarfed by the extra handling for the case when the user doesn't exist:
- we're doing formatted logging that we wouldn't otherwise do
- we're checking trace.IsNotFound three times
- the trace package generates backtraces for the errors which is a costly operation compared to checking a bcrypt hash

I suspect we'll have to stop using trace in order to really fix this.