Fix dmsgweb

[0pcom]

fix shadow variable issue which caused panic

[0pcom]

I've realized that the previous PRs did not fully implement the so-called "dmsghttp" method of connecting to the dmsg discovery over dmsg. Only dmsg-direct has thusfar been implemented.

I've updated the flags for some utilities to include both the dmsg-discovery URL and dmsg address - pending actually implementing the dmsghttp method of connecting to the dmsg network

Note: dmsghttp refers to too many different things regarding this software, including:

• the dmsghttp file server utility at cmd/dmsghttp
• the dmsghttp-config.json which is the deployment configuration included in the skywire repo
• the dmsghttp method of connecting to the dmsg-discovery via http client configured to use the dmsg-direct connection as a transport.

[0pcom]

dmsgweb is not working on skywire develop branch currently. I need it working in order to distribute rewards.

I have implemented 3 of the 4 methods for connecting to dmsg on this PR

The four methods are:

• direct client + using the dmsg-discovery over plain http to get the servers to connect to without registering in dmsg-disc <- how the skywire-services currently work

• direct client + using the embedded dmsghttp-config or dmsghttp-config.json file to get the list of servers to connect to without registering in dmsg-disc

• client registers with the dmsg-discovery over plain http <- default or preferred skywire visor config, previous default for dmsg utilities

• client registers with the dmsg-discovery over dmsghttp & use dmsghttp-config for bootstrapping <- skywire visors in china, etc.

The first one is not yet implemented because there is no way to specify a socks5 proxy for the http client, because the http client is not passed into the needed functions ; but instead declared directly inside those functions.

I can't change the function signatures without breaking things in skywire that use those functions.

So this effort will be revisited in a future PR.