Add liquidity griefing protection for liquidity ads

[t-bast]

When using liquidity ads, seller nodes may be vulnerable to liquidity griefing attacks. They may disable utxo locking to protect against such attacks, but the trade-off is that honest peers may also be affected by having their funding transaction double-spent. More details can be found in https://delvingbitcoin.org/t/liquidity-griefing-in-multi-party-transaction-protocols/264.

We thus expose a configuration flags to let node operators decide which trade-off they choose, depending on how likely they think someone will target them vs the UX they want to provide to their customers. Node operators can also choose to operate without this protection, and activate it when they detect that they're targeted.

We also add a mechanism to abort incoming channels after a configurable timeout in the second commit: if a remote node starts opening a channel to us and then becomes unresponsive, they're likely buggy or malicious so we want to fail that channel. Note that splicing already has this mechanism built-in using the quiescence-timeout parameter.

[sstone]

IIUC this fix (not locking UTXOs used for funding transactions), when enabled in the configuration file, is global and applies to all funding attempts. Would it make sense to restrict its applications to channel openings that we do not initiate and include liquidity requests (i.e. we would always lock inputs when we open channels)

[t-bast]

Would it make sense to restrict its applications to channel openings that we do not initiate and include liquidity requests (i.e. we would always lock inputs when we open channels)

Unfortunately we cannot do that, it doesn't work...this is detailed in the long comment in BitcoinCoreClient.fundTransaction, we must either always lock or never lock, there is no in-between (unless we use separate wallets, but this creates liquidity management issues).

[sstone]

the new timeout is a real improvement, the don't lock utxos option is probably not something we will use ourselves but it's better to be ready and could benefit other operators.