Closes coder/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 using conn.Close()
• Once finished, the tunnel sends a stop response
• The tunnel closes it's speaker's sendCh.
• The tunnel's serdes sendLoop discovers the sendCh is closed, and exits it's sendLoop, 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 the updater struct, whose context protects the sendCh 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 the updater to attempt to write to the sendCh 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.