Advanced autoconnection logic

[jdknives]

Feature description

We should implement a more resilient and performant autoconnection logic for visors. This should include the ability to detect opportunities to connect to other visors via stcpr or sudph directly and use these one hop routes.

Is your feature request related to a problem? Please describe.

We currently have a very basic autoconnection logic implemented. Upon startup we pull a number of public visors in and connect. This should create a number of transports that makes it easy enough to setup routes through the networkw without having to manually establish transports. The downside is that given the randomised logic behind picking servers to connect to, the routes established to conncet any two visors may be suboptimal and include multiple hops via Skywire where a single hop route would have been possible if further transports were established. sudph or stcpr transports directly to the remote are faster than mutli hop routes in most cases.

Describe alternatives you've considered

Clients could cache the list of available remotes via stcpr and sudph from AR if a route to one of these remotes is requested, they could establish a transport before requesting the route, possibly even circumventing the need to call the route finder and directly call the setup node. Other implementations may be possible.

[jdknives]

This could be solved somewhat easily by the visor performing these checks:

1. If the remote is either available stcpr or sudph, establish the transport to the remote and then continue with the route creation process.

2. If neither of these direct transports is available, check if automatic transports are currently active. If they are continue with route creation.

3. If none of the first two checks was successful, establish a dmsg transport and then continue with route creation.

It may be easier to not directly make this module part of the route creation process and instead just perform checks and then call the route creation process separately. This way the UI could call an endpoint for this module and upon it returning, start the route creation.