lnd v0.10.0-beta.rc2: highlighted feature and bug fix

[Olaoluwa Osuntokun]

Hi y'all,

Yesterday we cut the second release candidate of the upcoming lnd 0.10-beta
release. This release contains a number of compelling features, optimizations,
and as usual bug fixes. I'd like to call to attention one notable feature that
we'd like to have current send heavy services/businesses try out, and also a
bug fix that anyone deploying a mobile lnd application (in particular) will
want to take note of.

First the new feature: mpp payment splitting. Our prior release enabled
settings all the proper bits in invoices and the node announcement to signal
that we were able to _receive_ mpp payments. In this new release, we've now
finished drawing the rest of the owl, so lnd is now able to _split_ payments.
Along the way, we've also removed the invoice creation limit, and now allow
users to make payments above the current max payment limit if the invoice
specifies mpp (still some PRs we need to merge in the rc phase to finalize all
this).

Notably, these new features are only made available to users via the
"routerrpc" sub-server. Up until now we haven't really documented these
"sub-servers" much, as they were to be considered experimental and could break
at any time. With full mpp support now in-place, the "routerrpc" sub-server in
in particular should now be considered more stable. By the time 0.10 is launched
our api docs (api.lightning.community) should also now document all the
sub-server goodies. Y'all can find a staging version of the new API docs here
(still under flux):
https://www.guggero.org/lightning-api-master/#lnd-grpc-api-reference.

We'll have a full blog post dropping in the coming days, but in order to have
lnd actually _split_ payments, you'll need to specify a new argument:
`max_shards`. This controls how many splits we should attempt, and serves to
reign in the current divide-and-conquer algorithm (our plan here is to start w/
something simple and layer more stuff on later). If you operate an application,
business, or service that sends payments frequently on the network, we'd very
much like y'all to actively test this new feature and report back with any
issues or suggestions to the API. As always, we'll be reachable
on Slack, #lnd IRC, and our issue tracker.

Next, the major bug that was fixed. Along the way to attempting to optimize how many
addresses we scanned for during a rescan, we realized that a non-deterministic
bug could at times cause lnd to generate a change address in a "non-default
scope". This was problematic as when we go to _recover_ a user's seed, we only
check "default scopes". In short, default scopes are used to generate keys that
will ultimately become on-chain addresses, while non-default scopes are used
for things like multisig keys that never actually become an "address" in the
traditional sense.

This issue has now been resolved in lnd 0.10. The impact is that if you've
_recovered_ a wallet in the past using your seed (and the swept the funds
elsewhere), then you should try to recover the wallet _again_, as it's possible
there're chain addresses it missed at the time (funds still SAFU). If you
recovered the wallet, and then continued to use the node as normal, then you
only need to run `dropwtxmgr` as that'll force a full rescan. If anyone has any
questions or concerns w.r.t how to handle this sanity check process for their
user base, feel free to reach out privately.

With all that said, we're also planning a talk (IN VR!!!!111) soon diving
deeper into all the goodies contained in lnd 0.10. The talk will be this
Saturday at 11 AM PST. Y'all can find more details here:
https://twitter.com/udiWertheimer/status/1250423314696163330?s=20.

Also the release notes should near a more final form in the next few days,
thanks for y'alls patience.

-- Laolu