Send: improve PSBT funding by using new lnd RPC

[jharveyb]

Right now the send state machine computes TX outputs and constructs a PSBT; we need the connected LND instance to add an input to cover TX fees, and we also need to add the input that carries the input TaroCommitment.

Limitations & solutions:

• Right now the FundPsbt() call will always BIP69 sort the outputs, which would break existing split commitments. However, we have enough information to restore the original output layout.
• FundPsbt() will return an error if any inputs are attached that are not owned by the wallet, so we must use FundPsbt() before attaching our asset-bearing input.
• Without the asset-bearing inputs attached, FundPsbt() will underpay on fees. We can work around this by computing the fee needed to cover the asset-bearing inputs, increase the change output value by this amount, and later decrement the change output value.

Given that, we have some options for implementation:

1. Pass the PSBT as-is to the wallet via FundPsbt(), attach our input and key derivation info to the funded PSBT, reshuffle outputs, have the wallet sign via SignPsbt(), finalize with FinalizePsbt(). This would result in underpaying on fees.
2. Same as 1, but compute the fee impact of our asset-bearing input and increment the dummy output values before passing the PSBT to FundPsbt().
3. Update the FundPsbt() walletrpc call to make BIP69 compliance optional, so we don't have to reshuffle outputs in option 1.
4. Perform coin selection on the tarod side via ListUnspent(), attach the asset-bearing inputs, then use SignPsbt() and FinalizePsbt().

The initial implementation is using option 1, but it may be worth revising the FundPsbt() RPC call in the future to simplify this flow.

[nope78787]

Would this allow tarod to operate in "watch-only" mode?

If would be nice to hold the keys to Taro assets outside the daemon. Perhaps having multiple keys which can produce schnorr signatures using s threshold scheme.

[Roasbeef]

@nope78787 so this is the case already: tapd doesn't hold any private keys itself, instead the wallet abstraction handles that. The default implementation today is one backed by lnd's wallet RPC service.

[Roasbeef]

I think let's generalize this issue to supporting fully external PSBT inputs from RPC? So this would let a caller provide a PSBT for a custom spend, instead of tapd making the entire template as is.

[dstadulis]

fully external PSBT inputs from RPC? So this would let a caller provide a PSBT for a custom spend, instead of tapd making the entire template as is.

Great avenue for payment-channel functionality to work between tapd and lnd

[jharveyb]

Restriction on input types to segwit-only as mentioned here:

#605 (comment)

I think technically only the inputs for minting would need to be segwit, but not non-anchor inputs to a transfer. IMO this is a reasonable restriction but if we want to keep it maybe it should be documented somewhere, or enforced earlier in the freighter.