* Rather than rely on the legacy notification interface which may be
deprecated in the near future, we’ll now switch to using the
NotificationSever.
* Negative confirmation notifications due to re-orgs are still
unimplemented however.
* Re-orgs are still unhanded.
* RegisterSpendNtfn should perhaps also register directly with the rpc
client instead of pushing the responsibility to the caller.
* The `NotificationTrigger` struct has been dropped. Instead we know
simply employ a non-blocking send over a chan struct. This moves the
responsibility of triggering callbacks a level above to the registering
client.
* Confirmation notifications also now have a counter part in order to
notify a caller of the scenario wherein a funding transaction drops out
of the chain due to a re-org. A “neagtiveConf” value will be sent to
the client over a channel in this case. This will allow a caller to
re-register for another confirmation notification. Note that due to
this scenario, callers should also register for notifications
concerning spends of the counterparty’s inputs to the funding
transaction. If a second spend (other than the funding) is detected,
the channel should be closed immediately.
* Notifications concerning spends now also include the spending
transaction, hash, and the input on the spending transaction at which
the outpoint is spent.
* Currently depends on the wallet, but that will change in the near
future due to new additions to btcwallet currently under review.
* Re-orgs aren’t intelligently handled yet. To be done along with tests
in a later commit.
* So far very simple, only notifications for tx confirmations, and
outpoint spends.
* Our two cases are: waiting for the funding transaction to reach a
depth of N confirmations, and open channels being notified of the
counterpart trying to cheat them by broadcasting an invalidated
commitment tx.
* Goal is to backend agnostic source to chain notifications
* Open channels will communicate with this source to register intent
for critical notifications
* Pending notifications will need to be committed to disk.
* Will also need a journal to ensure no notification is missed
* Later goals include extending this to communicate with 3rd party
outsource services
