multi: use getTransaction grpc for confirmCoinbases.

[dnldd]

This reworks coinbase confirmation function to uses the getTransaction grpc to fetch transaction details and confirm them. The rescan begin height is now a coinbase maturity length of blocks from the lowest reported block with a tx having inaccurate confirmation information. Tests have been updated.

[jholdstock]

Added a few comments, mostly for myself to remember I need to re-review some of the points later.

---

The reason we originally used TxConfNotifications to track when coinbases become spendable was because of a race condition explained here in #222.

The old confirmCoinbases blocked until all of the coinbases were spendable. I don't think the new one is blocked, so it seems like it will be prone to the same race condition.

[dnldd]

I don't think the issue described in #222 is going to be a problem here since gettxout was informing us of what the node knew about the provided tx output not factoring in the wallet's state concerning that output (the wallet could be updated late for example). The current solution being used in confirmCoinbasesV2 is calling the wallet's gettransaction grpc for the transactions of interest. If the wallet doesn't know about them yet it will have two more blocks to do so before a rescan is performed. The disparity we had before concerning the information the wallet and node had at a given time on a tx shouldn't be an issue now since we ask the wallet to confirm txs it will need to create the payout transaction directly, however we'll still have to confirm gettransaction works as expected and the expanded rescan range is adequate in mitigating the current tx confirmation issues being had with recieving tx confirmation notifications.

[jholdstock]

Understood. Will deploy onto my test site and monitor for a few days.