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

…lits

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

@@ -298,6 +298,15 @@ func (p *paymentSession) RequestRoute(maxAmt, feeLimit lnwire.MilliSatoshi,
 			// route, try it for half the amount.
 			maxAmt /= 2
 
+			// If this shard ends up being too large, then we'll
+			// clamp it down to the max shard size if that's set.
+			//
+			// TODO(roasbeef): extend the integrated routing tets w/ info
+			maxShardActive := p.payment.MaxShardAmt != nil
+			if maxShardActive && *p.payment.MaxShardAmt > maxAmt {
+				maxAmt = *p.payment.MaxShardAmt
+			}
+
 			// Put a lower bound on the minimum shard size.
 			if maxAmt < p.minShardAmt {
 				p.log.Debugf("not splitting because minimum "+