Potential changes / refactoring in the transaction subscription model

[da-kami]

The idea of the transaction subscription model was inspired by solving these problems:

• downsize N requests for information from the node to 1
• pass subscriptions around as sole data structures
• decouple the refresh-rate from the number of network requests

Over time the implementation has changed. This discussion collects some improvement proposals. I want to avoid spending time on trying to make things better without having some consensus first. I tried to list things in a distinct way that allows tackling them separate. I think (1.) could just be converted into an issue.

1. With the recent changes for Mainnet switch #446 we changed the subscription to fetch the latest block (subscription to block headers) to poll for every subscription. This is not efficient because the latest block is independent of the subscription for a transaction. I think updating block headers should be separately handled in the bitcoin::wallet::Client.

2. Is subscribing to the script a necessity? If possible, it would simply things a lot if we could subscribe to transaction updates by txid only. The fine granular filter per script is somewhat of an overkill for the purpose of this piece of code, as we just want to know how many confirmations the transaction has.

3. I find the relationship between subscriptions and subscribe_to a bit hard to understand. The fact that there should only be exactly one subscription for each transaction is not obvious. We can subscribe multiple times (as in to the subscription), but the subscription should only be one for each transaction. Maybe subscriptions should actually be watchables? Or subscribe_to should actually be watch?

4. We should work towards a state machine model where the Subscription can actually be passed around. At the moment we use subscribe_to a lot, which in most cases just returns an already existing Subscription to a transaction - that subscription could just be passed around rather than re-using it and keeping track of all the listeners. As powerful as this sender/receiver model is, I wonder if it isn't an overkill that just resulted out of the current overall state machine architecture. Would be cool if we could simplify that on the way.