Enable user to apply available updates without additional prompts

[eloquence]

The current update sequence is as follows:

1. User logs in.
2. Preflight updater checks for updates (takes several minutes).
3. If updates are available, user has to explicitly click a button to apply them.

We did this because updates can't be interrupted, so we wanted to give the user an explicit choice to end their session if they don't have time to run them.

Unfortunately, this has a major UX downside: we're demanding the user's continued attention during the process. I think anything we can do to reduce our demand on users' time and attention would be a big win.

An alternative approach would be to have a "Cancel" button during the "Checking for updates" stage, and to ask the user on that screen to cancel if they do not wish to apply updates. If updates are found, we would apply them immediately.

[eloquence]

I've milestoned this as Post-Beta given the pending feature freeze; I do think it could be a nice win in our first release after the pilot launch.

[eloquence]

As a cleaner and faster approach, we discussed in sprint planning that it makes more sense to combine the "check for updates" and "apply updates" steps. We'll simply prompt the user to proceed or cancel once at the beginning of the process, and if they proceed, we do everything (uncancellable) in a single operation.

This would reduce the number of VM restarts and should speed up the overall process.

@ninavizz Let's talk about this a bit more and figure out what the dialogs would say, but I think that makes a lot of sense. Aiming to take a stab at this, this sprint.

[eloquence]

So, my thinking right now is that it makes the most sense to keep the two stages, but to execute the "Installing updates" stage immediately. There would be a "Cancel" button on the "Checking for updates" stage, and that button would be disabled during the "Installing updates" stage. Language below still very much WIP (@ninavizz and I are discussing), but to give you an idea:

What I'm unclear about is if we really have to shut down the VMs in the first stage, as we're doing here. It seems like this (and the associated error tracking) could be deferred unless we detect that no updates are available.

If we're smarter about shutting down VMs, I don't see any performance gains in merging the two stages into one. Keeping the "Checking for updates" and "Installing updates" stages separate gives us a few benefits:

• We can start the process immediately, without an "Are you sure you want to do this" screen, because the "Checking for updates" stage will never be instantaneous.

• We can have more accurate progress bars, instead of finding out at "85%" that we need to pull some slow update over Tor.

• The scope of proposed changes is smaller, making this iteration easier to review and reducing the risk of regressions.

Let me know if I'm missing something; will discuss more synchronously with Mickael, as well.

[eloquence]

Talked through this with @emkll and there is in fact a performance reason to consolidate the two stages: the update-vm Salt state itself will refresh the package index, so we don't need to also do it during the "Checking for updates" stage.

qubesctl does use a management VM that has to start and shutdown, which is slightly slower than our qvm-run approach, but we'd save an expensive HVM startup/shutdown cycle, so may still be overall faster even when no updates are available, and would definitely be faster when there are Debian updates.

This would also greatly simplify the code and ensure we rely on upstream code as much as possible, which gets us closer to consolidating update strategies per #302.

This does mean we would have to add a "Continue/Cancel" type screen at the beginning of each update, because the process would be un-cancellable once it's kicked off.

[eloquence]

Screenshots of flow in WIP branch implementing the above, for discussion:

[ninavizz]

Thoughts as pixels w/ annotations.