fix RepeatTimer memory leak (Refs #137)
* test case
* drain channels on reset
Leaking memory:
```
leaktest.go:144: leaktest: leaked goroutine: goroutine 116 [chan send]:
github.com/tendermint/tmlibs/common.(*RepeatTimer).fireRoutine(0xc42006a410, 0xc4203403c0, 0xc42031b2c0)
/go/src/github.com/tendermint/tmlibs/common/repeat_timer.go:160 +0x6e
created by github.com/tendermint/tmlibs/common.(*RepeatTimer).reset
/go/src/github.com/tendermint/tmlibs/common/repeat_timer.go:196 +0xe9
```
The alternative solution could be draining channels on the client side.
* add one more select instead of draining
thanks to Jae
Fixes https://github.com/tendermint/tmlibs/issues/145
Fixes https://github.com/tendermint/tmlibs/issues/146
The code in here has been fragile when it comes to nil
but these edge cases were never tested, although they've
showed up in the wild and were only noticed because
the reporter actually read the logs otherwise
we'd have never known.
This changes covers some of these cases and adds some tests.
Lesson articulated by @jaekwon on why we need 80 bits
of entropy at least before we can think of cryptographic
safety. math/rand's seed is a max of 64 bits so can never
be cryptographically secure.
Also added some benchmarks for RandBytes
Fixes https://github.com/tendermint/tmlibs/issues/99
Updates https://github.com/tendermint/tendermint/issues/973
Removed usages of math/rand.DefaultSource in favour of our
own source that's seeded with a completely random source
and is safe for use in concurrent in multiple goroutines.
Also extend some functionality that the stdlib exposes such as
* RandPerm
* RandIntn
* RandInt31
* RandInt63
Also added an integration test whose purpose is to be run as
a consistency check to ensure that our results never repeat
hence that our internal PRNG is uniquely seeded each time.
This integration test can be triggered by setting environment variable:
`TENDERMINT_INTEGRATION_TESTS=true`
for example
```shell
TENDERMINT_INTEGRATION_TESTS=true go test
```