txdb lock balance accounting fixes.

[pinheadmz]

The assertions were only there in the first place because of weird covenant accounting: for some covenants like REVEAL, we dig up the corresponding BID from the database and we MUST HAVE THAT DATA or we can't compute the change to the wallet's locked balance.

The new approach is: we process all inputs and all outputs of every TX, meaning that the BID in the input of the transaction is applied to our balance mere moments before we process the REVEAL in the output of the same transaction. This simplifies balance locking really well (we eliminate DB lookups and the functions are no longer async/await).

The assertion errors we've been getting almost daily from users occurs when the BID is not in the database yet because we don't recognize our own address because it's a wallet recovery and we haven't generated the address yet.

What this PR does is "not care": if we see a REVEAL before we see the BID, then we have a negative locked balance. Yep that really sucks but it can be fixed with a rescan or two... and no one's node has to crash.

There is one other drawback to this, which is why I'm pausing here and opening as draft:

TODO:

• [ ] class Balance in txdb needs to allow negative values. Remove assert >= 0 and switch all writeU64 to writeI64 which interestingly, because it's javascript, I think means we don't need a migration ... ?!

[coveralls]

Coverage decreased (-0.03%) to 67.755% when pulling e74ac100a49cae83ac93308b28a6919772e8fc92 on pinheadmz:txdb-unlock-balances into e07ba5427bdc0e2e030af59f4da42ccbb6f5aff7 on handshake-org:master.

[pinheadmz]

@nodech rebased on master and discovered another failed test from #781

I don't know if this issue is recoverable. I'm using these extra log statements to monitor the un/lock balance activity:

https://gist.github.com/pinheadmz/9af90d54e7ac934a7aa331ccd6501f28