Add support for multi-trampoline payments

[t-bast]

Electrum has made great progress recently in their trampoline implementation. Electrum wallet will ship with a model similar to Phoenix, where they connect to the Electrum node which provides trampoline routing.

We should use a static list of known trampoline nodes, which would contain for now:

• ACINQ (03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f)
• Electrum (03ecef675be448b615e6176424070673ef8284e0fd19d8be062a6cb5b130a0a0d1)

When paying an invoice that sets the trampoline feature bit, we should look at its routing hints to see what node it's connected to. If it's connected to a different trampoline node from ours, we should use 2 trampoline hops to reach the recipient.

The end result would be payments with this kind of route:

   +--------------------+ +-------------------------------------------+   +-----------------------+
   |                    | |                                           |   |                       |
   |                    v |                                           v   |                       v
Phoenix -------------> ACINQ ------------> N1 ---> ... ------------> Electrum -------------> Electrum Wallet
          (private)            (public)                  (public)               (private)

[robbiehanson]

Related question: Do we allow the user to add custom node(s) to this list ?

[t-bast]

No, we want trampoline to go through the RFC review process before we allow any kind of extensibility, otherwise it will be a mess to maintain and a nightmare to provide user support.

Electrum is an exception because they built a full lightning implementation, a lightning wallet and integrated trampoline before its acceptance in the spec.

[t-bast]

This is too far away on the roadmap to be worth an issue at that point, closing.