Description
With #1613 we have the ability to split a payment across multiple shards to have a higher probability of payment success.
We don't have much control over the rate limits used used. Currently we only have taproot-assets.experimental.rfq.acceptpricedeviationppm to control if a rate is too high. This is a bit unflexible because we may only need a small shard to be sent through a high rate peer and the weighted average rate for all shards of the entire combined payment could be well under taproot-assets.experimental.rfq.acceptpricedeviationppm if most other outbound capacity is much lower than taproot-assets.experimental.rfq.acceptpricedeviationppm.
Would like to see some way to limit taproot-assets.experimental.rfq.acceptpricedeviationppm more intelligently based on the shard size actually used to send the payment.