Execute app shutdown vetoes in sequence

[msujew]

What it does

Closes #10860

Since we prioritize actions anyway, it didn't make a lot of sense to execute the actions in parallel. For example, if we have the following two OnWillStop results, the second one returns first, even though its priority is lower:

[{
  reason: 'a',
  priority: 10,
  action: async () => {
    await timeout(10);
    return ...;
  }
},{
  reason: 'b',
  priority: 0,
  action: async () => {
    return ...;
  }
}]

How to test

1. Create a new multi-root workspace and don't save it
2. Edit a file in your workspace and don't save it
3. Exit the app
4. Any shutdown action returning false will prevent execution of subsequent actions

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[colin-grant-work]

The motivation for running the actions in parallel is that it's possible for an action to resolve itself without any user intervention (e.g. terminals need to check whether there are running processes in the terminals, which is asynch but may end up finding none). In that case, running several such actions in sequence would only delay shutdown. Is there a definite reason for wanting to run the actions sequentially?

[msujew]

I liked the parallel approach initially as well, however I noticed one issue in particular with it: When we have multiple FrontendApplicationContributions which have their own dialog to ensure that the user definitely wants to quit the app - even though it would be wise not to - every dialog after the first canceled dialog is completely useless and has no effect on the shutdown procedure. This is kind of bad UX in my opinion.

The reproduction/testing steps show this issue fairly well with the base app. This becomes more exaggerated in downstream Theia apps, where there are more conditions which might prevent the app from shutting down gracefully.

[colin-grant-work]

Ah - that clarifies the problem for me. It definitely makes sense to bail after the first rejected option. Your code definitely does that - let me think a moment about other possibilities.

[colin-grant-work]

The current implementation was influenced by VSCode's, and VSCode has the same problem: if you have two vetoes with dialogs (e.g. dirty file and terminal), canceling one doesn't stop the next one from appearing. I don't really see an alternative to running in sequence if we want to avoid showing meaningless dialogs.

[msujew]

@colin-grant-work I have an idea which should at least alleviate the issue of "data that needs some time to be prepared". What if we change the OnWillStopAction to be:

interface OnWillStopAction<T = undefined> {
  reason: string
  priority?: number
  prepare?(): MaybePromise<T>
  action(prepared: T): MaybePromise<boolean>
}

We could run OnWillStopAction#prepare in parallel, while passing the prepared return values in sequence into the action method. WDYT?

[colin-grant-work]

... WDYT?

@msujew, I think I like it :-).

[colin-grant-work]

This looks good to me. It should not break any implementations oriented to the older behavior, but it does provide flexibility and cancel any irrelevant dialogues.