wallet: bump lookahead to 200

[pinheadmz]

Closes #407
...but in a lazy way that more kicks the can down the road than anything.
See this comment specifically for details.

TODO:

• run benchmarks.
• fix tests (generate 200 addresses from bitcoin core and maybe verify with one other implementation for test vectors)

Update:

This was lowered from 1000 to 200 because in the serialized account metadata, the lookahead value is only a single byte:

hsd/lib/wallet/account.js

Line 747 in 7826128

bw.writeU8(this.lookahead);

benchmarks:

master branch

account: ops=1000, time=3.276540621, rate=305.19994

PR branch

account: ops=1000, time=46.609575762, rate=21.45482

No big surprise there - creating an account makes generating 20x more keys (380 total because of receive & change).
So we've increased account creation time from ~3ms to ~46ms

[coveralls]

Pull Request Test Coverage Report for Build 243442873

• 2 of 2 (100.0%) changed or added relevant lines in 1 file are covered.
• 3 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.01%) to 59.218%

---

Files with Coverage Reduction	New Missed Lines	%
lib/net/pool.js	1	32.63%
lib/net/peer.js	2	35.28%

Totals
Change from base Build 238010293:	-0.01%
Covered Lines:	19385
Relevant Lines:	30471

---

💛 - Coveralls

[tynes]

It's nice to see the benchmark for account creation. I'm curious about how it would impact the performance of a rescan. If it's using a bloom filter then it should just be building the bloom filter that takes longer.

As performance becomes an issue, maybe https://github.com/chjj/bthreads/ can be used.

[pinheadmz]

Interesting idea to use threads to generate keys in parallel. I know walletDB has workers but I'm not sure if they're used in rescanning. Off the top of my head, that seems like the kind of thing that must be done serially because of the UTXO system.