Routing with dmsg transports breaks routing rules ; multi-path & server-server optimizations

[0pcom]

Original issue / background info

skycoin/skywire#1826

Dmsg servers are unaccounted intermediaries in dmsg transports - multihop route traffic may transit the same server multiple times

the connection between two dmsg clients is fully mediated by the dmsg server and is not maintained in the absence of the connection to a dmsg server.
Hence the dmsg server is an intermediary in this connection which is not currently accounted for. By specification, a route should not transit the same public key twice, however, the public key of the dmsg server is not accounted for in the transports. Dmsg servers do not directly or wittingly take part in transports, seemingly by design.
Hence it is crucial that any attempt to create a route through the same dmsg server multiple times shall be thwarted by some means. Yet other important implications also arise.

Dmsg Parallel Connection Optimization

In the instance that dmsg clients are connected to more than one dmsg server by default, it should either be possible to take advantage of both the possible paths at once

Dmsg Servers -to- Server Connections

In a technical sense it is clear that not every dmsg client and not every visor may connect to every other over dmsg currently. This is due to the fact that every visor would need to be connected to every other visor via the same dmsg server. The scaling limit was increased somewhat by the visor connecting to 2 dmsg serves by default, however, it is currently the case that if both dmsg servers you are connected to have no available sessions, other clients will no longer be able to connect to your client that can't connect to at least one of the same dmsg servers.
It would make sense in light of this, to have dmsg servers connect to each other and via that connection, to be able to connect clients which are connected to different dmsg servers thereby overcoming the aforementioned scaling limitation.