APK metadata can have incorrect apkFileName

I've encountered a case where the apkFileName is not being filtered from the "APK metadata" as should be done here: https://salsa.debian.org/reproducible-builds/diffoscope/-/blob/master/diffoscope/comparators/apk.py#L234

I've attached two files which can reproduce the issue: a.img and b.img

$ diffoscope --force-details a.img b.zip
--- a.img
+++ b.img
├── filetype from file(1)
│ @@ -1 +1 @@
│ -Linux rev 1.0 ext2 filesystem data, UUID=bad69392-b955-4573-b958-e202e5f44fd5 (large files)
│ +Linux rev 1.0 ext2 filesystem data, UUID=f56fc32c-9f6a-49bc-965e-fb7c3bbd9b09 (large files)
│   --- a.img.tar
├── +++ b.img.tar
│ ├── file list
│ │ @@ -1,4 +1,4 @@
│ │ -drwxr-xr-x   0 root         (0) root         (0)        0 2021-05-09 07:19:43.000000 ./
│ │ -drwx------   0 root         (0) root         (0)        0 2021-05-09 07:19:43.000000 ./lost+found/
│ │ --rw-r--r--   0 root         (0) root         (0)      866 2021-05-09 07:20:08.000000 ./test1.apk
│ │ --rw-r--r--   0 root         (0) root         (0)        3 2021-05-09 07:20:04.000000 ./hi
│ │ +drwxr-xr-x   0 root         (0) root         (0)        0 2021-05-09 07:19:45.000000 ./
│ │ +-rw-r--r--   0 root         (0) root         (0)        3 2021-05-09 07:20:19.000000 ./hi
│ │ +drwx------   0 root         (0) root         (0)        0 2021-05-09 07:19:45.000000 ./lost+found/
│ │ +-rw-r--r--   0 root         (0) root         (0)      866 2021-05-09 07:20:15.000000 ./test1.apk
│ ├── ./test1.apk
│ │ ├── APK metadata
│ │ │ @@ -1,9 +1,9 @@
│ │ │  !!brut.androlib.meta.MetaInfo
│ │ │ -apkFileName: 2.apk
│ │ │ +apkFileName: 3.apk
│ │ │  compressionType: false
│ │ │  doNotCompress: null
│ │ │  isFrameworkApk: false
│ │ │  packageInfo: null
│ │ │  sdkInfo:
│ │ │    minSdkVersion: '2'
│ │ │    targetSdkVersion: '23'

The issue is that apkFileName is either 2.apk or 3.apk depending on the order in which the file was added to the filesystem image. While there is a difference between a.img and b.img, that difference should only be in the UUID and the file listing, not the file names. Since test1.apk is identical between the two images, I've had to add --force-details to force it to look into the APK, but I've encountered this issue in normal usage (without --force-details), where there were other differences between the APKs inside the filesystem.

I also tried to reproduce the issue when the APKs were inside another type of container (zip instead of ext2 fs), but I didn't encounter the issue then.

---

The files a.img and b.img were produced by running

$ echo hi > hi
$ mke2fs a.img 512K
$ debugfs a.img -w -R "write hi hi"
$ debugfs a.img -w -R "write test1.apk test1.apk"
$ mke2fs b.img 512K
$ debugfs b.img -w -R "write test1.apk test1.apk"
$ debugfs b.img -w -R "write hi hi

where test1.apk is from tests/data/test1.apk.