Problem

1. When loading/saving a resource with loadFromDevice()/saveToDevice() MD5 of the resource changes. Therefore, we cannot use resource->md5() when writing the embedded resource tag.

2. We have a lot of presets in the default bundle, whose MD5 links are broken because of this problem.

3. Right now we have a policy: if resource is not found by MD5, then we don't even check filename and name tags. It causes the embedded resource to be fetched all the time, because it cannot find the resource it has already loaded from embedded storage. It introduces huge delays on painting. See this bug https://bugs.kde.org/show_bug.cgi?id=443629

Proposed solution consists of two stages:

Stage 1:

1. When loading an embedded resource, first try to fetch with the saved MD5 tag.
2. If it fails, try to calculate MD5 of the embedded data and use it for fetching. This calculation takes about 4ms, which is quite a lot, so we should evaluate if this step is really needed.
3. If it fails, fallback to filename and name to fetch the resource.

At this stage this bug will be "fixed": https://bugs.kde.org/show_bug.cgi?id=443629 Though we will not be guarded from this problem in the future. With every update of libpng and/or Qt MD5 links will become broken again, and we will basically use name/filename as keys. Therefore, I propose the second stage:

Stage 2:

4. If resource is not present in the database, KoResource::embeddedResources() returns QByteArray with data of the resource instead of a built up KoResource object. It will let us preserve resource's MD5.
5. This QByteArray is then passed to a modified version of KisResourceLocator::importResourceFromFile(), which copies the resource into the storage.
6. For optionally returning QByteArray we can use a std::expected-like structure (needs research to check if it is possible).
7. When saving an embedded resource, we should either generate MD5 for the actual saved data (instead of using resource->md5()) or add something like KisResourceLocator::exportResourceToFile(), which just copies underlying data from the storage and, therefore, preserves MD5.