Roflcoptor should close connections if clients go away

[dma]

Reproduce:

• Run ricochet in oz in SGOS
• Kill oz-daemon while sandbox up/app running
• Start oz-daemon
• Try to run ricochet again in oz in SGOS
• TorHS collision, ricochet can't setup listener
• Probably roflcoptor's fault: ephemeral hidden services go away when the client connection to the tor control port is closed.

[david415]

so... if there were multiple applications that were relying on their own onion services via roflcoptor... and roflcoptor sees a connection close it should close it's control port destroying all the onion services? i think the solution here is for roflcoptor to DEL_ONION the specific onion service corresponding to the application that closed it's connection to roflcoptor.

[special]

Tracking ADD_ONION and issuing DEL_ONION when the app->roflcopter connection is closed would work for this case, but it's going to be fragile and it will leave similar problems like GETINFO onions/current unsolved.

I think a much better solution would be to make one roflcopter->tor connection for each application->roflcopter connection, and close them at the same time. All of tor's per-connection behavior would then be automatically correct.