Context

As a result of the high level research of routing variations, the best suited solution for our purposes is static routing. Following up on the draft implementation PR here, there are a few more points to be added:

• If next hop is the destination connector, then it shouldn't make any difference in the routing logic. Currently this case is handled separately.
• Static routes must be specified on peer creation and added to the in memory routing table.
• Wildcard/mask support i.e. being able to route all traffic that has destination in the format test.* through a specific next hop.
• (Optional) Each route should have a different weight based on the best exchange rate of all possible next hops. This is different from rate probing (AFAIK) as rate probing happens after the payment path is found. Weights should not be static but rather calculated and updated at some interval.

To do

Finish implementation, update/add routing tests as well as test this feature on the localenv