The hypervisor returns inaccessible visors

[Senyoret1]

Describe the bug
When calling GET http://{localIp}:8080/api/visors the hypervisor appears to return the list of all the nodes that have been connected to it, even if there is no connection to them anymore. Also, the response does not include any info indicating if the visor is connected to the hypervisor.

Environment information:

• OS: Linux (Ubuntu 18.04.1)
• Platform: Linux 4.15.0-65-generic x86_64

Steps to Reproduce
Steps to reproduce the behavior:

1. Start some nodes using the make integration-run-generic command of the skywire-services repository

2. Call GET http://{localIp}:8080/api/visors. You should get a list with 3 visors.

3. Call GET http://{localIp}:8080/api/visors/024ec47420176680816e0406250e7156465e4531f5b26057c9f6297bb0303558c7. You should get the basic info of the visor.

4. Go to the console window used in step 1, press Ctrl+b and then 6 to open the tab of the first visor. Then press Ctrl+c to stop the visor.

5. Call GET http://{localIp}:8080/api/visors again. You should still get a list with 3 visors, but most of the fields of the 024ec47420176680816e0406250e7156465e4531f5b26057c9f6297bb0303558c7 visor will now be empty.

6. Call GET http://{localIp}:8080/api/visors/024ec47420176680816e0406250e7156465e4531f5b26057c9f6297bb0303558c7 again. You should get "error": "connection is shut down".

Actual behavior
GET http://{localIp}:8080/api/visors returns nodes that are not connected. One way to tell which nodes are not connected is by checking if the node_version and app_protocol_version fields are empty, but the problem is that the API endpoint sometimes return those fields empty for valid visors. Maybe that is related to #28 .

Expected behavior
Only connected visors should be returned. If returning visors that are not connected is a measure to minimize the effects of #28 . Then a procedure to deal with the problem should be created, because this issue affects the ability to show a list of connected nodes to the user.

Additional context

Possible implementation
Similar to #28 :

If there is any serious complication for implementing a solution in the hypervisor, the client could implement something like a “noice cancellation” procedure to detect in which cases the hypervisor is just having a temporary disconnection. This would sometimes make the UI slower but should work.

If this is going to be done, it would be good to document the need to do so in some location related to the API, including ways to detect the disconnection and the amount of time in which a reconnection could be expected, so anyone implmenting the API is aware of the need to do something similar.

[Senyoret1]

This was initially tested using the mainnet-milestone2 branch. I tested it again using the master branch and the problem is present there too.