[feature]: `SendPayment`: allow specifying fee limits in terms of the asset being sent and not sats

[ZZiigguurraatt]

SendPayment (https://lightning.engineering/api-docs/api/taproot-assets/taproot-asset-channels/send-payment/) is for sending assets defined by an asset_id in a tapchannelrpc.SendPaymentRequest. Also must be defined in tapchannelrpc.SendPaymentRequest is payment_request, which is an object of type routerrpc.SendPaymentRequest from SendPaymentV2 (https://lightning.engineering/api-docs/api/lnd/router/send-payment-v2/). SendPayment is a wrapper for SendPaymentV2, so we need to specify fee_limit_sat in routerrpc.SendPaymentRequest in terms of sats.

However, from a user standpoint, they currently need to compute what the fee limit should be in sat, based a current quote from their channel peer that is exchanging their asset for sats. This can be confusing for the sender because they may not really have any sats to send as fees, and they don't want to send real sats, they only the asset they are trying to send to be used as fees. The sender also should not have to figure out what the current quote is going to be used for the current call to SendPayment and calculate an equivalent sats fee value in terms of the asset they are trying to send.

Please add a new field to tapchannelrpc.SendPaymentRequest, fee_limit_asset, and if present, override fee_limit_sat in payment_request.

Also, consider fixing lightningnetwork/lnd#7832 instead of, or in addition to this issue.

[ZZiigguurraatt]

I am thinking that fixing lightningnetwork/lnd#7832 might be more useful to application developers because they won't have to also call DecodeAssetPayReq to see what percentage of the total amount the fee_limit_asset being set is.

[ZZiigguurraatt]

We should clarify in the documentation when this is implemented that the fee_limit_asset is converted to a fee_limit_sat using the edge node buy price from the RFQ and not the sender's sell price from their own price oracle. I think it should be based on the edge node buy price from the RFQ because that will then include the "implied fee" that is discussed in #1367 .

[ZZiigguurraatt]

I am thinking that fixing lightningnetwork/lnd#7832 might be more useful to application developers because they won't have to also call DecodeAssetPayReq to see what percentage of the total amount the fee_limit_asset being set is.

Also,it seems as though DecodeAssetPayReq does not use the RFQ to determine the asset amount. See also #1368 .

[ZZiigguurraatt]

This is going to be a bit harder with #1613 because we will have a different asset rate for each shard and LND doesn't have the ability to have a different fee limit for different shards. Likely it will be easiest to just use the worst quote for now, especially if #1559 and/or #1560 are fixed.