Download add-ons in the BG for automatic update notifications

[seanbudd]

Link to issue number:

Fixes #17722

Summary of the issue:

When using the automatic update notifications, users must wait until downloads complete before exiting the add-on update dialog. Instead, downloads can be pre-fetched, and the user can decide to update all add-ons using the pre-downloaded add-ons, or discard updates.

Description of user facing changes

When using automatic update notifications the new UX is:

1. Job starts, automatic update is set to notify or automatic update
2. Job fetches and downloads updatable add-ons
3. If update notification is set to notify, open the notification dialog
   1. If the user presses update all - the installation is immediately queued and the dialog is closed. Before you had to click close after update all, and retry closing until downloads are complete.
   2. If the user opens the add-on store to decide which add-ons to update, the add-ons are pre-fetched, and the installation should happen faster
   3. If the user presses close, the downloads are cleared on NVDA restart

Description of development approach

1. Ensure trying to download an add-on which has successfully already been downloaded in the current NVDA session doesn't retry the download.
2. Improve typing for add-on collections
3. Pre generate list VMs and download add-ons before branching between automatic BG installation and update notifications, so the same downloads and VMs are used for either path

Testing strategy:

Tested manually using the add-on store test plan. Added missing test section for automatic updates in the background

Known issues with pull request:

Similar logic could potentially be applied to the Add-on Store itself as discussed in #17722

Code Review Checklist:

• [x] Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• [x] Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• [x] UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• [x] API is compatible with existing add-ons.
• [x] Security precautions taken.

@coderabbitai summary

[CyrilleB79]

Is there an impact for the following use cases?

• users with low bandwidth
• users experimenting instable connection (e.g. background download interrupted)
• users with no active internet connection
• if the user have very big add-ons installed; I think that some OCR or AI add-ons weight many hundreds of MB.
• combination of these use cases

[seanbudd]

Hmm making this configurable is possible - I'd need to ensure the second download attempt doesn't block the main thread again. We'd also probably want to consider Content-Length before pre-fetching for bigger add-ons

[SaschaCowley]

Yeah, personally, I wouldn't want to see this merged with out at least the option to disable prefetching add-ons.

I think ideally we would have:

1. The ability to enable, disable, and only enable for unmetered connections; and
2. The ability to set the maximum size of automatically downloaded add-ons.