Add argument to OpenChannel rpc to input UTXOs

[saubyk]

To simplify app development for coin selection on channel opens an additional argument should be added to the OpenChannel rpc. This argument should take an array of UTXOs which the application (user) passes. The processing logic should also include fee estimation, which enables complete UTXO consumption with no change output being generated.
Two scenarios to explain the requirement.

Scenario 1: User selects coins to use and specifies the amount to open the channel with. This can result in a change output being generated depending upon the amount in coins and fee rate chosen (essentially same as current functionality but with selected UTXOs)
The OpenChannel rpc will be called with:

• utxo argument
• amount
• fee rate (default or chosen by the user)

Scenario 2: User selects coins to use and indicates to use them whole. This should result in no change output.
The OpenChannel rpc will be called with:

• utxo argument
• fundmax flag as true
• fee rate (default or chosen by the user)

The scope of change includes:

• lncli
• grpc
• REST API

fundmax flag is introduced with the below pr:
#6903
Related issue:
#6949

[hieblmi]

@saubyk As mentioned in #6949 I'd like to take a shot at this issue.

One thought regarding Scenario 2.
Wouldn't it make sense to omit the fundmax flag and take the missing local_amt as indicator that the entirety of the --utxos is going towards the channel funding? This would also tie in with the current user experience when only specifying local_amt. We'd have:

• lncli openchannel --node_key=xxx --local_amt yyy -> spends entirety of local_amt
• lncli openchannel --node_key=xxx --utxos utxo1,utxo2,utxo3 -> implies to spend entirety of the 3 utxos
• lncli openchannel --node_key=xxx --utxos utxo1,utxo2,utxo3 --local_amt yyy -> spends yyy sats from the 3 utxos

[saubyk]

@hieblmi when it comes to providing options, my preference is always to be explicit rather than implicit. But I would let someone more qualified than I am on this, to chime in
cc: @guggero @Roasbeef

[guggero]

I agree with making things as explicit as possible. Otherwise it might happen that I forget --local_amt and my node just creates the largest channel it can. We could discuss using the value of -1 for --local_amt instead of an additional flag (at least on the command line, would probably still use the flag on the RPC), but not sure if that makes things any more clear.

[hieblmi]

I am working on tests for edge-cases in the coin selection and wanted to get your thoughts on the following scenario.

Suppose we have two coins in our wallet, say 100_000 and 8_000 sats. If we open an anchor channel and select the utxo with100_000 sats and specify a local amount of 100_000 - miner_fee - 2_000 then I would expect the opening to succeed since we keep 10_000 in total in our wallet to cover for the anchor reserve.
Do you agree that this is the behavior that we want?

[guggero]

Do you agree that this is the behavior that we want?

Sounds like the expected behavior, yes. So the check for the anchor reserve should take into account the full wallet balance and not only the selected UTXOs.

[hieblmi]

Ok, it sounds obvious. I was asking this in the context of the fundmax flavor of this flow already taking care of the reserve during coin selection whereas the local-amt flow has to be adjusted to account for the reserve. I will note this in the related PR #7516.