`skywire-cli ut` ; `skywire-cli proxy` ; `skywire-cli vpn` queries respect dmsghttp-config

[0pcom]

The service discovery queries will try to use the visor's config value for service discovery. Which could be a dmsghttp url, which is where the error comes from here: https://github.com/skycoin/skywire/issues/1659

if you have that dmsghttp-config then the cli would want to connect to SD via dmsg directly, which is not working correctly yet as implemented in this PR https://github.com/skycoin/skywire/pull/1679

I thought there was some api for the visor to do service discovery & uptime tracker queries ; perhaps we took that out because it was overly complicated.

skywire-cli proxy list / skywire-cli vpn list / skywire-cli ut desired behavior:

What should happen if one of the above three commands is run? ;

In the instance there is a visor running locally:

• skywire-cli asks the running visor to query the SD / UT <-- Not implemented (has API?)

In the instance there is no running visor locally:

• connect to the SD or UT URL specified via flag to skywire-cli (dmsg:// or http://) <-- Not implemented

• an optional flag to be used with dmsg:// URL for specifying dmsg server <ip>:<port> to connect to for dmsg-direct query <-- Not implemented / issues with implementation https://github.com/skycoin/skywire/pull/1679

If a URL is not specified via flag for the SD or UT:

• skywire-cli should attempt to use the service discovery or uptime tracker URL in the visor's config ; assuming that the config for the visor is detected in one of three standard places: -- the current dir ( i.e. running from source) -- the package path (/opt/skywire/skywire.json) or -- the config path in the user space (~/.skywire/skywire.json or ~/.skywire/skywire-config.json)

• optional flag to specify config path

If no config is detected

Two options remain:

• fetch the relevant parts of the config from http://conf.skywire.skycoin.com or from the dmsghttp endpoint that the conf service is served on (I'm not sure if conf serves over dmsghttp currently) ; then do the query to SD or UT with that.

• fall back on hardcoded defaults (http:// or dmsg://).

...

We should make sure not to do any http queries:

• if there is a visor running locally with a dmsghttp-config.
• if a visor config for dmsghttp is found in any of those places.
• In the instance that flags specify to use either dmsg or dmsg-direct (not implemented currently)