ManagePage: one failed update should not cancel all updates

[Feichtmeier]

If one presses update all and one of the updates can not be made because the app is running, the update all should still happen with the ones that are updateable (if this is a word)

[d-loose]

Related issues: #1391, #1643

[d-loose]

Just a small update - the snapd API docs say:

POST /v2/snaps
...
Fields
...
transaction: optional string field, defaulting to per-snap if not present. If all-snaps is used, the action field will be performed such that the corresponding change will have a single transaction covering all the snaps. If in this case there is a failure for any snap, the state of all affected snaps will be fully reverted, even if for some snap the action has been successful. This field is valid for install and refresh actions. See Transactional updates for more details

So in principle it should be possible to refresh multiple snaps via a single API call and errors that occur during the refresh of an individual snap shouldn't affect the other ones.
However, in practice that doesn't seem to work:

Example with two snaps that are up to date:

$ snap refresh steam signal-desktop
All snaps up to date.

Example with two snaps, where one is currently running:

$ snap refresh steam firefox
error: cannot refresh "steam", "firefox": snap "firefox" has running apps (firefox), pids:
       6167,...

The first command creates a snap change, as expected, but the second one doesn't:

$ snap changes
ID    Status  Spawn                      Ready                      Summary
2621  Done    today at 14:58 CEST        today at 14:58 CEST        Refresh snaps "steam", "signal-desktop": no updates

Possible workarounds

• Passing an empty list of snaps to snapd (has the same effect as running snap refresh). In this case errors that occur while refreshing an individual snap will be silently ignored.
• Refreshing each snap individually (as previously done in the community store). Besides known issues with that (polkit authentication would be invoked multiple times, unless we wait until the first snap in the list is refreshed, and loop through the remaining ones afterwards), we'd need to handle each transaction separately to track their progress and watch for possible errors.

[d-loose]

Confirmed with the snapd team that this is indeed expected behavior. The per-snap transaction type affects only the transaction(s) that are spawned after initial checks. They recommend the same to options I posted above and plan to improve the verbosity of snap refresh in the future.

[Feichtmeier]

@d-loose great improvement with your latest pr!

polkit authentication would be invoked multiple times, unless we wait until the first snap in the list is refreshed, and loop through the remaining ones afterwards)

Beside that would eventually be a little bit slower I think this would also have the advantage of seeing the progress indicators of all the snaps individually. The polkit thing is not visible for the users so I don't think this should matter that much