Adjust handling of app updates based on a new importance property

There are three importance levels:

• OPTIONAL: The update is performed silently when the user visits the next time or reloads manually. This is intended for minor improvements and bugfixes.
• RECOMMENDED: The update dialag is shown after the service worker has loaded the newer version (previous behavior).
• MANDATORY: The update dialog is shown immediately. The update button is disabled util the service worker has loaded the newer version. This is intended for breaking changes in the API.

Because the user might have skipped previous updates, the actual importance level is determined based on multiple versions. So instead of the latest version, a list of recent versions is now retrieved. The actual importance is the highest importance of all versions newer than the currently installed one. If the installed version is no longer part of the list, MANDATORY is implied.

The commit hash of the latest available version is now stored locally. If the app is loaded at a later time, the importance of an MANDATORY update is degraded to RECOMMENDED when its ID is lower or equal to the ID belonging to the locally stored latest version. As a result, the update dialog is only forced once. This is done to prevent blocking of the UI permanently if something went wrong.

The ID of the installed version is no longer stored locally. Instead the commit hash is used which is build into the app.

A new dimension and Event for the app version and updates are now tracked with the version ID and commit hash.

What needs to be tested

• Mandatory updates
  • The dialog should be forced (showed immediately, confirm button disabled until update is ready) if there is a mandatory update.
  • The dialog should no longer be forced if the app was already loaded once when the update was already available. In this case the previous behavior is applied (dialog shown once update is ready).
• Optional updates
  • Optional updates should not trigger a dialog.
• Recommended updates
  • The old behavior (dialog shown once update is ready) should apply.
• Skipped updates
  • If there were multiple updates in the meantime, the behavior for the highest importance of those update should be applied.
  • The changelog of the latest updates which contains changelog entries should be shown.
  • If the currently installed version is not part of the version list (e.g. 201201 for the example below), the mandatory behavior should apply.
• First app installation
  • The behavior for recommended updates should apply.

Example config (backend-core)

For testing the commit hash does not need to match a real commit - it can be an arbitrary string. The commitHash of one of the versions need to be set in src/environments/environment.prod.ts.

arsnova:
  ui:
    versions:
      - id: 201206
        commitHash: < Current Commit Hash >
        importance: OPTIONAL
        changes:
        # no change list here
      - id: 201205
        commitHash: < Previous Commit Hash >
        importance: MANDATORY
        changes:
          en:
            - a change
            - and another change
          de:
            - eine Änderung
            - und noch eine Änderung
      - id: 201204
        commitHash: < Old Commit Hash 1 >
        importance: RECOMMENDED
        changes:
          en:
            - a change
            - and another change
          de:
            - eine Änderung
            - und noch eine Änderung
      - id: 201203
        commitHash: < Old Commit Hash 2 >
        importance: MANDATORY
        changes:
          en:
            - a change
            - and another change
          de:
            - eine Änderung
            - und noch eine Änderung
      - id: 201202
        commitHash: < Old Commit Hash 3 >
        importance: OPTIONAL
        changes:
        # no change list here