Make AppImages updateable

This merge request is implementing self-update capabilities for AppImages inside Krita. Apart from integration of the tools into Krita's codebase, there are also updated scripts for AppImage building and icons for update channels.

There are multiple parts to this patch:

1. C++ code for integration of AppImageUpdate and changes to previous update notifications Both of those options are called Updaters. There is:

• The Manual Updater, which is in fact a fancy name for checking for new version on the website and displaying a message to the user together with a link to the release notes. This is the original update notification code, I have slightly modified version checking and moved the code into it's own class.
• The AppImage Updater, which is used if Krita detects that it runs from an AppImage. This updater can actually download new version of Krita, if it is available.

2. updated scripts for building appimages
   I have added code to bundle AppImageUpdate into the AppImage being built. Also, the build scripts infer the update channel (stable, Beta, Plus or Next) from a combination of Krita version and git information. This info is used for setting up proper update channel and selecting the right branding option. I have also added helper scripts for signing the already built AppImage (sign_appimage.sh; also strip_appimage_signature.sh and validate_appimage_signature.sh for debugging purposes) and rewriting update information of the built AppImage (update_updinfo.sh).

3. icons for update channels
   I have added icons I made for myself to make sense of all my AppImages. The icons are in krita/pics/branding, together with a script for generating all icon sizes from svg (generate_icons.sh).

Changes to building - there are two new cmake flags:

1. ENABLE_UPDATERS (bool, can be ON or OFF) - this flag toggles all updater code, both the appimage updating and update notifications
2. BRANDING (string, can be default, Beta, Plus, or Next) - this flag controls which app icons will be installed

The Phabricator task: https://phabricator.kde.org/T11467. Apart from the technical details it also contains images/videos of current state, a list of unfinished work and a deploy plan for this feature.

Test Plan

Note: This is a howto for testing this for the needs of the code review. Deployment and beta testing scenarios will be addressed elsewhere.

Testing without infrastructure

The appimage can be tested without the infrastructure parts.

1. Build the appimage with -DBUILD_TESTING=TRUE, so that AppImageUpdateDummy is included in the appimage.
2. Export variables that control the dummy updater and then run the appimage in terminal:

   export KRITA_APPIMAGEUPDATER_USE_DUMMY=true
   export APPIMAGEUPDATE_DUMMY_STATE="check_uptodate"
   ./Krita.AppImage

Available states are:

• check_uptodate
• check_update_avail
• check_error
• check_updinfo_empty
• update_ok
• update_error
• runtime_error

---

Testing end-to-end with building and infrastructure

There are two updates to test: the manual updater (which just takes new release info from RSS) and the appimage updater.

Manual Updater

For manual, you will need:

• a webserver
• a local copy of Krita's RSS feed.

1. Set up your webserver to serve static files from a directory.

2. Set the webserver to listen on localhost:8000, copy your local feed to the static directory, name it feed.xml
   OR
   Modify the feed URL in KisManualUpdater to match your environment

3. Craft a release news item on top of the feed (krita cares only about the title and link, other parts may be arbitrary).

4. Play with the news item title and test what it does on Krita's welcome page. You can reload the feed without restarting Krita by toggling the “Check for updates” checkbox off and on again.

AppImage Updater

For appimage, you will need

• Docker container for building Krita
• Http server capable of serving ranges (e.g. nginx)

1. Setup the webserver Setup your webserver to listen on localhost:8000 and serve static files from a directory
   OR
   Modify build-image.sh to point to different URLs (ZSYNC_URL)

2. Setup the docker container (https://docs.krita.org/en/untranslatable_pages/build_krita_with_docker.html)

3. Now we need to build two versions of Krita, here we reference them as older and newer
   A. Enter the container
   B. build krita and the appimage
   appimage@machine:<srcdir>/packaging/linux/appimage>./build-krita.sh <builddir> <srcdir> && ./build-image.sh <builddir> <srcdir>
   C. Copy the appimage to persistent directory
   D. Update your source (you will need a new git revision, not only changes in source) and build another appimage

4. Sign the appimages
   A. Generate a gpg key (gpg --gen-key)
   B. Get the ID of the signing key (the long hex number in output of gpg --list-keys)
   C. Sign the appimages, first the older, then the newer.

• This needs to be done in the correct order: signing regenerates the zsync file, so it has correct metadata.
• Channel depends on the branch that is used to build the appimage. For master, use ‘Next’, for other git branch use ‘Plus’. If in doubt, please refer to build-image.sh.

$ <srcdir>/packaging/linux/appimage/sign_appimage.sh <path-to-appimage> <target-channel> <gpg-key-id>

5. Upload appimages and .zsync file to the webserver.

6. Run the older appimage. Test updating.

Formalities Checklist

• I confirmed this builds.
• I confirmed Krita ran and the relevant functions work.
• I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
• I made sure my commits build individually and have good descriptions as per KDE guidelines.
• I made sure my code conforms to the standards set in the HACKING file.
• I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.