Don't return `UNKNOWN_NEXT_PEER` for MPP timeouts

[TonyGiorgio]

I'm trying to analyze why some payments fail to Phoenix users and I've stumbled upon incorrect error messages returned by your LSP that causes lightning routing algorithms to repeatedly consider the same Phoenix user to be unpayable until resetting the state of the routing algo.

I have done this multiple times to reproduce the issue.

1. Make a large invoice on Phoenix, one that would result in a new channel (not sure if it makes a difference)
2. Pay it from an LND node
3. Eventually the LND node attempts through MPP
4. If one of the parts makes it, it is held for ~60s while more parts are attempted. If they don't attempt in time, your ACINQ node returns UNKNOWN_NEXT_PEER for the part that made it
5. Further attempts to pay the invoice will also result in an instant 'no route found' error since it is incorrectly indicating that the peer does not exist.

Solution: Return a different error message for MPP timeouts

[t-bast]

If they don't attempt in time, your ACINQ node returns UNKNOWN_NEXT_PEER for the part that made it

We only return UNKNOWN_NEXT_PEER when the Phoenix user is disconnected and we can't get it to reconnect. I agree though that this isn't the ideal error for this case, and we already had this discussion several times in the past. Using temporary_channel_failure without a channel_update would make more sense, but the spec doesn't allow this yet (someone should open a spec PR for that!).

The reason this wasn't changed is that there was general agreement that it doesn't make sense to blacklist channels that come from routing hints when receiving UNKNOWN_NEXT_PEER (especially when no other routes can be found): I thought lnd had fixed that a while ago?

[TonyGiorgio]

I think this is just an issue for me because I'm using graphene and there's issues pushing notifications to my phone.