Closescoder/coder-desktop-macos#51.

The shutdown process for the VPN using the dylib is as follows:

• The manager (Swift, C#) sends a stop request.
• The tunnel receives the request & stops all tailnet goroutines usingconn.Close()
• Once finished, the tunnel sends a stop response
• The tunnel closes it's speaker'ssendCh.
• The tunnel'sserdessendLoop discovers thesendCh is closed, and exits it'ssendLoop, which, in turn closes the file descriptor for writing on the tunnel's side.

We note that during this process, no contexts are cancelled. If we were to cancel contexts, it would introduce a race between the cancellation, and the stop response being sent - it would be possible for the stop response to never get sent. Unfortunately, there's one context in this process that we do need to cancel, and it's theupdater struct, whose context protects thesendCh from the ticker for periodically updating the manager with the network state of peers.

As we never cancelled the tunnel context (my bad!), it was possible for theupdater to attempt to write to thesendCh after it was closed, causing a panic in the dylib. Since we can't cancel the tunnel context, we'll just cancel the updater context.

This meant stopping the VPN, and then starting it before that timer fire would cause the VPN to fail to start, as the panic would happen on the old process and crash the new VPN instance. If you just stopped the VPN, no error would be reported as the panic wouldn't be noticed once the OS stops caring about the status of the VPN.

This was an issue in two scenarios:

• Stopping and then quickly starting the VPN via the GUI.
• When we tried to implement starting and stopping the tunnel on wake & sleep.

This patch fixes both of these scenarios.