Limit the output following depth

[cdecker]

Status quo

onchaind adds a txowatch for the funding output of a channel when
the funding transaction is confirmed. This is so that lightningd can
inform onchaind and other channel-specific daemons about spends that
they are interested in.

The notification of spends is asynchronous, and so lightningd
implements an auto-follow logic: if an output we are watching is being
spent, then we add the spend transaction's outputs also to the set of
watch TX outputs. This allows for correct tracking despite onchaind
handling the notifications asynchronously.

This however also means that if onchaind is very slow, for example
because the signer is not present, and we're waiting on a signature,
then this adds new outputs to the watched set faster than we can
unsubscribe the not interesting ones.

We've seen at least one case in which a channel closing resulted in
50k UTXO spend notifications being queued up, and a similar number of
txowatch instances.

Solution

Channels have a predictable max depth of interesting transactions for
onchaind. For example the longest chain that I can think of at the
moment is:

1. Funding output
2. HTLC second stage output
3. HTLC second stage sweep output
4. HTLC second stage sweep anchor spend

So if we add a maxdepth field to the txowatch we can count that
down every time we create a descendant txowatch from a parent, and
if it hits 0 we do not follow further. By setting maxdepth to a
large(-ish) number (say 10) we still follow correctly, but no longer
risk picking up some mixer structure that fans our attention out to
thousands of outputs to follow.

Impact

The sheer number of UTXO spends being replayed during startup was
causing onchaind to fall further and further behind, all the while
the front of observed UTXOs was increasing rapidly.