Routes are not being created again

[Senyoret1]

Describe the bug
If you send a msg from one node to another node, some routes are automatically created. However, if those routes are deleted and you try to send the msg again, the routes are not created again.

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 (tested using the milestone2 branch of the skywire-mainnet repo and the mainnet-milestone2 branch of the skywire-services repo).
2. Create transports connecting the nodes by calling POST /api/visors/0348c941c5015a05c455ff238af2e57fb8f914c399aab604e9abb5b32b91a4c1fe/transports with {"remote_pk":"024ec47420176680816e0406250e7156465e4531f5b26057c9f6297bb0303558c7","transport_type":"dmsg","public":true} as content and then again with {"remote_pk":"031b80cd5773143a39d940dc0710b93dcccc262a85108018a7a95ab9af734f8055","transport_type":"dmsg","public":true} as content.
3. On the command window used to run make integration-run-generic run now curl --data {'"recipient":"'$PK_A'", "message":"Hello Joe!"}' -X POST $CHAT_C. This will send a msg to VisorA (it will appear on the console).
4. Use the GET /api/visors/{visor}/routes API endpoint to se how the previous step created routes on all 3 visors.
5. Use the DELETE /api/visors/{visor}/routes/{routeID} API endpoint to remove all the routes from all the visors.
6. Repeat stept 3 to try to send a msg again. The console will not show an error while trying to make the operation, but the console for VisorA will not show the msg, so the msg is not really sent.
7. Use the GET /api/visors/{visor}/routes API endpoint again to see the routes of each visor. Visors will continue to have 0 routes.

Actual behavior
Routes are not created again after being deleted. Also, trying to send the msg will not show an error, but the msg will not be sent.

Expected behavior
The routes should be created again and the msg should be sent normally.

Additional context
May be this is related to #44

Possible implementation

[Darkren]

not sure but may be related to #147 , probably worth checking against #152

[nkryuchkov]

@Darkren Still happens against #152