[feature]: SendPayment: allow specifying an implied_fee_limit

[ZZiigguurraatt]

Consider the following

                     TA               sats
          Alice ------------- Bob ------------ Charlie
         hungry              edge              merchant
         woman               node

When alice is sending a sending a taproot asset through bob, we have an "implied fee". This is because bob needs to make some profit, so there will be a difference between his buy and sell price. Likely his sell price will be similar to alice's sell price and alice's buy price may be similar to bob's buy price, because they both want to make profit off an exchange. However, sometimes you need to make an exchange rather than want to make an exchange.

The "implied fee" is not directly collected. It's alice's perception based on her view of the marketplace for the taproot asset she is trying to sell. She gets that view of the marketplace from her price oracle. If Alice does not have a price oracle, she can't know what the implied fee is and basically assumes it is 0.

OK, now for an example:

Charlie creates an invoice for 400 sats for a candy bar and gives it to alice. In this case, Alice needs to make an exchange because she is hungry. Alice and her price oracle think 100 assets = 1 sat, that is their sell rate. Therefor, alice thinks she should have to send 40,000 assets to pay the invoice with no implied fee because that is what she sees when she runs DecodeAssetPayReq.

She also knows that Bob will charge a normal LN routing fee of 1 sat for this payment.

When she does an RFQ with bob, she finds out he (and his price oracle) thinks 110 asset = 1 sat because that is the buy rate that he advertises. He wants her to pay 44,110 asset. Her "implied fee" rate is then

=(Bob_Buy_Rate-Alice_Sell_Rate)
=(110 asset/sat - 100 asset/sat)
=10 asset/sat

For a 400 sat invoice with a 1 sat LN routing fee, that comes out to an "implied fee"

= 10 asset/sat * 401 sat
= 4010 asset

and

=  4010 asset * alice_sell_rate
=  4010 asset / (100 asset/sat)
~= 40 sat

Now, although alice doesn't agree with bob on the price, she may still accept his price because she needs his exchange service (she is hungry) and consider the difference between their prices as the "implied fee".

You could say that alice did not pay an "implied fee", she just shifted her sell price to bob's buy price because she was hungry and needed to make an exchange. However, I argue this "implied fee" is a way to quantify alice's price shift as a fee from her ideal. It's also a way for bob to quantify his markup that he is making on the deal.

Remember, these "implied fees" are from the perspective of alice. Since the marketplace is decentralized, there is no true asset price. There can always be a difference in buy and sell price between each buyer and seller. Alice uses the information that her oracle provides to assess what she thinks the "implied fee" should be.

When using SendPayment, we need the ability to limit the "implied fees". We have experimental.rfq.acceptpricedeviationppm (

taproot-assets/sample-tapd.conf

Lines 363 to 366 in 9202f08

	; The default price deviation inparts per million that is accepted by
	; the RFQ negotiator.
	; Example: 50,000 ppm => price deviation is set to 5% .
	; experimental.rfq.acceptpricedeviationppm=50000

), but that is fixed and can't be set on a per payment basis. Also, we should be able to choose to limit "implied fees" based on percentage (implied_fee_limit_percent), asset units (implied_fee_limit_asset), OR sats (implied_fee_limit_sat). This way we can use similar units for defining both "implied fees" required to exchange an asset and normal/real LN routing fees (note, I'm also hoping #1204 and lightningnetwork/lnd#7832 will be fixed too).

In addition to accepting an implied fee limit as an input to SendPayment, the actual implied fee should be returned once the payment succeeds.