Currently TunnelManager.deleteAccount() is somewhat fragmented.

DeleteAccountOperation that it schedules only runs a network request that deletes account from backend, but it leaves the part for removing the tunnel and logging out device on completionHandler.

Completion handler executes on main queue however it taps into private unsetTunnelConfiguratin() which returns control back on private queue. Subsequent call back to UI continues on the same private queue which violates UI threading model (all UI calls must happen on main queue)

We should perhaps look into consolidating the entire "deletion" logic inside of DeleteAccountOperation and keep completion handler as simple as the following snippet:

func deleteAccount(
    accountNumber: String,
    completion: ((Error?) -> Void)? = nil // 1
) -> Cancellable {
    let operation = DeleteAccountOperation(/* ... */)
    operation.completionQueue = .main // 2
    operation.completionHandler = { [weak self] result in
        completion?(result.error) // 3
    }

Note that operation will ensure that completion is dispatched on main queue.

Also: I suggest to look at how SetAccountOperation works with .unset action. Maybe we could reuse it to provide additional .delete action (for ex. SetAccountOperation.unsetDeviceState() does very much the same thing as unsetTunnelConfiguration() from TunnelManager).

If you decide to consolidation account deletion + tunnel removal into DeleteOperation then don't forget to add the following exclusivity category for the operation to make sure nothing else attempts to mutate system VPN configuration while operation is running:

operation.addCondition(MutuallyExclusive(category: OperationCategory.manageTunnel.category))

Side note on current architecture of tunnel manager

1. For the most part TunnelManager is a collection of operations that do their individual tasks. The manager sets dependencies between operations depending on what they do: mutate device state, settings, or touch system VPN configuration or any permutations of that.

2. Some shared functionality that those operations often tap into is consolidated in TunnelInteractorProxy (private type) and injected via init() to each individual operation.

   This is basically a front for TunnelManager that hides private functions from the outside world but exposes it to operations via abstract protocol TunnelInteractor that private TunnelInteractorProxy implements.

   Example how to instantiate interactor (from within TunnelManager):

   TunnelInteractorProxy(self)
   

3. Functions exposed by TunnelInteractor all rely on nslock (NSLock) to deal with races because some of them tap into public props like deviceState or settings which are often touched by other parts of the app.

4. Operations use serial internalQueue to run internal work but also as a general rule of thumb, they tend to always switch back to that queue if some of sys calls come back on background threads. This design makes it a bit easier to debug and understand what's going on with the tunnel manager state, although not the most elegant given that we also have lock in use. Obviously all that can be gradually improved down the road.