Reduce storage requirements for teos

[sr-gi]

Problem statement

teos is currently designed to run on top of bitcoind using txindex=1. The rationale for this is potentially having to query the block height where a monitored transaction was included in order to account for its confirmations. That is:

• When a transaction is sent to bitcoind (through sendrawtransaction) it could be the case that the transaction is already known by our node (by either being in mempool or already in a block). In the latter, we need to query the block height of the block that included the transaction so we can monitor until it gets IRREVOCABLY_RESOLVED. That's done by both querying getrawtransaction, parsing the block_hash, and then querying getblockheader.
• If a reorg is detected, we need to know whether the transaction that is being monitored (e.g. penalty), and potentially its parent (e.g. commitment) have been reorged. To know so, getrawtransaction is queried and the block_hash is pulled.

In both cases, we are querying getrawtransaction for transactions that are not part of our wallet, hence requiring txindex=1. Unfortunately, running with transaction indexing is incomparible with pruning, which means the node needs to download and keep a full version of the chain (~430 GiB at the time of writing).

Potential solutions

txindex + prune

The simplest solution, albeit probably the hardest, would be to PR Bitcoin Core and add support for txindex in prunning mode. There does not seem to be any technical reason not to have this feature (bitcoin/bitcoin#12651): It has been proposed in the past but rejected for not being interesting enough (or not having a well-defined / reasoned use case).

Being able to run txindex for the last n blocks in the chain will allow us to have the same functionality while maintaining the simplicity of the codebase.

Pinging @willcl-ark given, after some conversations during BTCAzores, he seemed pretty interested in championing this into Core.

Descriptor wallets + gettransaction

As previously state, the only reason why we need txindex is that we are querying transactions that do not belong to any of our wallets. A potential solution (proposed by @darosior also during BTCAzores) would be to use descriptor wallets alongside gettransaction to query the necessary data. This would work as follows:

For every blob that we decrypt we get the channel funding outpoint and add its descriptor as watch-only. This will allow us to query gettransaction instead of getrawtransaction (or most likely a combination of both, the former for data on chain and the latter for data in the mempool) for its descendants, meaning it will cover both the commitment and the penalty.

Foreseeable issues

• Adding a descriptor optionally triggers a chain rescan to look for transactions that may belong to that wallet. In our case, we need to trigger such a rescan, given some data may be on-chain by the time we decrypt the blob (especially in the generalized case where decrypted data is not belonging to a lightning channel). However, this could enable DoS attacks on the tower where transactions are constantly triggered so it has to continuously rescan the chain. Therefore, the rescan has to be bounded. Intuitively, we should rescan 100 blocks at max, given that's our threshold for considering something IRREVOCABLY_RESOLVED. Some testing would be needed to see how expensive that could be.
• Deleting descriptors seems not to be an option in the current version of Core. Hence, data may potentially linger around forever. Also, it is unclear how adding many descriptors could affect the performance of scanning for new ones.

Build our own txindex

We could also build our own txindex in a similar fashion to how we built the LocatorCache for the Watcher. This would mean having an index of blocks (potentially tracking the last IRREVOCABLY_RESOLVED blocks), which may imply a couple of maps:
a block_hash -> (tx_ids, height) map, and a txid -> block_hash map. The index will need to be populated/pruned when a new block is connected/disconnected*.

*Notice that all reorg logic would need to be managed by us since currently, we offload some of it to bitcoind.

[sr-gi]

We ended up going for the latest option: #132