[bug]: `litcli ln payinvoice` should not have an option `--outgoing_chan_id`

[ZZiigguurraatt]

Looking at the documentation for the payinvoice CLI, we have an option for --outgoing_chan_id. However, that seems to conflict with --rfq_peer_pubkey, so I think we should remove it. The same thing goes for litcli ln sendpayment. Not sure if this should be fixed as part of lightninglabs/lightning-terminal#1052 or in a separate PR.

4bb544a08a1e:/$ litcli ln payinvoice -h
NAME:
   litcli ln payinvoice - Pay an invoice over Lightning, potentially using a multi-asset channel as the first hop.

USAGE:
   litcli ln payinvoice [command options] pay_req [--asset_id=X | --group_key=X] [--rfq_peer_pubkey=y] [--allow_overpay]

CATEGORY:
   Payments

DESCRIPTION:
   
  This command attempts to pay an invoice using an asset channel as the
  source of the payment. The asset of the channel must be specified using
  the --asset_id or --group_key flag.
  

OPTIONS:
   --pay_req value              a zpay32 encoded payment request to fulfill
   --fee_limit value            maximum fee allowed in satoshis when sending the payment (default: 0)
   --fee_limit_percent value    percentage of the payment's amount used as the maximum fee allowed when sending the payment (default: 0)
   --timeout value              the maximum amount of time we should spend trying to fulfill the payment, failing after the timeout has elapsed (default: 1m0s)
   --cancelable                 if set to true, the payment loop can be interrupted by manually canceling the payment context, even before the payment timeout is reached. Note that the payment may still succeed after cancellation, as in-flight attempts can still settle afterwards. Canceling will only prevent further attempts from being sent
   --cltv_limit value           the maximum time lock that may be used for this payment (default: 0)
   --last_hop value             pubkey of the last hop (penultimate node in the path) to route through for this payment
   --outgoing_chan_id value     short channel id of the outgoing channel to use for the first hop of the payment; can be specified multiple times in the same command
   --force, -f                  will skip payment request confirmation
   --allow_self_payment         allow sending a circular payment to self
   --data value                 attach custom data to the payment. The required format is: <record_id>=<hex_value>,<record_id>=<hex_value>,.. For example: --data 3438382=0a21ff. Custom record ids start from 65536.
   --inflight_updates           if set, intermediate payment state updates will be displayed. Only valid in combination with --json.
   --max_parts value            the maximum number of partial payments that may be used (default: 16)
   --json                       if set, payment updates are printed as json messages. Set by default on Windows because table formatting is unsupported.
   --max_shard_size_sat value   the largest payment split that should be attempted if payment splitting is required to attempt a payment, specified in satoshis (default: 0)
   --max_shard_size_msat value  the largest payment split that should be attempted if payment splitting is required to attempt a payment, specified in milli-satoshis (default: 0)
   --amp                        if set to true, then AMP will be used to complete the payment
   --time_pref value            (optional) expresses time preference (range -1 to 1) (default: 0)
   --asset_id value             the asset ID of the asset to use when sending payments with assets; cannot be used at the same time as --group_key
   --group_key value            the group key of the asset to use when sending payments with assets; cannot be used at the same time as --asset_id
   --rfq_peer_pubkey value      (optional) the public key of the peer to ask for a quote when converting from assets to sats; must be set if there are multiple channels with the same asset ID present
   --allow_overpay              allow sending asset payments that are uneconomical because the required non-dust amount for an asset carrier HTLC plus one asset unit is higher than the total invoice/payment amount that arrives at the destination; meaning that the total amount sent exceeds the total amount received plus routing fees
   --amt value                  (optional) number of satoshis to fulfill the invoice (default: 0)
   
4bb544a08a1e:/$ 

[ZZiigguurraatt]

Actually, maybe --outgoing_chan_id does not necessarily always conflict with --rfq_peer_pubkey, but I think it could be.

Thinking more, wondering though if we can have --rfq_peer_pubkey not required if --outgoing_chan_id is defined? It seems as though --outgoing_chan_id will always be more specific than --rfq_peer_pubkey???

[guggero]

Good point. I think we should change things so you can either specify the outgoing channel ID or the RFQ peer. Both indeed doesn't make sense, as they do influence each other (with the channel ID being more precise in case there are multiple channels with the same peer).

This should definitely be its own PR though.