routing: if MaxShardAmt is set, then use that as a ceiling for our splits

In this commit, we thread through the necessary state to allow users to
set a max shard amount. If this value is set, then this'll effectively
serve as a ceiling for all our split attempts. If we need to split,
we'll first try to use `paymentAmt/2`, if that's bigger than
`MaxShardAmt, then we'll use the latter instead.

Ideally in the future we have a dynamic way to automatically set both
the `MaxShardAmt` as well as `MaxParts` for users. Until then exposing
these two new fields will allow us to experiment with setting them
automatically using the RPC interface, and also give users a bit more
control over how we attempt to route payments, akin to coin control for
on-chain payments.

Fixes #4730

routing/payment_session.go

@@ -230,6 +230,18 @@ func (p *paymentSession) RequestRoute(maxAmt, feeLimit lnwire.MilliSatoshi,
 
 	finalHtlcExpiry := int32(height) + int32(finalCltvDelta)
 
+	// Before we enter the loop below, we'll make sure to respect the max
+	// payment shard size (if it's set), which is effectively our
+	// client-side MTU that we'll attempt to respect at all times.
+	maxShardActive := p.payment.MaxShardAmt != nil
+	if maxShardActive && maxAmt > *p.payment.MaxShardAmt {
+		p.log.Debug("Clamping payment attempt from %v to %v due to "+
+			"max shard size of %v", maxAmt,
+			*p.payment.MaxShardAmt, maxAmt)
+
+		maxAmt = *p.payment.MaxShardAmt
+	}
+
 	for {
 		// We'll also obtain a set of bandwidthHints from the lower
 		// layer for each of our outbound channels. This will allow the
@@ -279,7 +291,8 @@ func (p *paymentSession) RequestRoute(maxAmt, feeLimit lnwire.MilliSatoshi,
 			}
 
 			if !p.payment.DestFeatures.HasFeature(lnwire.MPPOptional) {
-				p.log.Debug("not splitting because destination doesn't declare MPP")
+				p.log.Debug("not splitting because " +
+					"destination doesn't declare MPP")
 
 				return nil, errNoPathFound
 			}