[feature]: `AddInvoice`: add an option `min_num_extra_hop_hints` for when when `private=true` and `currentAmount >= targetAmount`

[ZZiigguurraatt]

I have a node with many private channels and no public channels and I try to create an invoice with lncli addinvoice 1 --private on that node . The invoice only includes a single hop hint because the channel it added as a hop hint has plenty of liquidity. In the code, this is because that direct channel has enough liquidity to meet targetAmount.

lnd/lnrpc/invoicesrpc/addinvoice.go

Lines 798 to 824 in df1a15f

	// sufficientHints checks whether we have sufficient hop hints, based on the
	// any of the following criteria:
	// - Hop hint count: the number of hints have reach our max target.
	// - Total incoming capacity (for non-zero invoice amounts): the sum of the
	// remote balance amount in the hints is bigger of equal than our target
	// (currently twice the invoice amount)
	//
	// We limit our number of hop hints like this to keep our invoice size down,
	// and to avoid leaking all our private channels when we don't need to.
	func sufficientHints(nHintsLeft int, currentAmount,
	targetAmount lnwire.MilliSatoshi) bool {
	if nHintsLeft <= 0 {
	log.Debugf("Reached targeted number of hop hints")
	return true
	}
	if targetAmount != 0 && currentAmount >= targetAmount {
	log.Debugf("Total hint amount: %v has reached target hint "+
	"bandwidth: %v", currentAmount, targetAmount)
	return true
	}
	return false
	}

If I give the invoice to the payer and they try to make the payment, the payment can fail for multiple reasons

1. Their only path to that hop hint has a disabled channel
2. Their only path to that hop hint does not have any liquidity.
3. etc.

I'd like to be able to set a min_num_extra_hop_hints so that I can have the route hints limited by both liquidity and number of channels. This should give some more diversity and probability of success.

To do this most intelligently, we should first sort the candidate channels for hop hints based on their liquidity so that we don't accidentally select just one channel added as a hop hint with a lot of liquidity and then the other channels added as hop hints only have a tiny amount of liquidity not enough to route the entire payment, but the one large channel that does have capacity can't be routed through for some reason.

More specifically, if there are N total hop hints, we should be able to sort the hop hints by liquidity and if we take the smallest (N-min_num_extra_hop_hints) and still have enough net liquidity to route the payment. In the example above, any channel should be able to route a 1 sat payment, but if the invoice amount is for something like 1,234,567 sat, it might not.