tests/upgrade: drop the rollback deployment on aarch64

[HuijingHei]

We need to drop the rollback deployment. During upgrade
...-> 40.20240906.1.0 (A)-> 41.20241109.1.0 (B)-> 42.20241114.91.0 (C)

1. A->B, A has the unfixed ostree, the upgrade will copy dtb files
   to /boot/ostree both for current A and new B with wrong label
2. B->C, B has the fixed ostree, the upgrade will prune A, leave B
   with wrong label, and new C with correct label
3. Finaly booting C and will check that B has the wrong label
   In this case we need to drop the rollback before checking.

If then upgrade to newer D, the upgrade will prune B (wrong label),
leave C with correct label, and new D with correct label. (We
should remove the drop under this case)

Refer to code from Dusty's comment

[HuijingHei]

Do testing with this patch, the result is passed.

$ cat tmp/target_stream.bu 
variant: fcos
version: 1.0.0
storage:
  files:
    - path: /etc/target_stream
      mode: 0644
      contents:
        inline: |
          rawhide

# cosa buildfetch --build=37.20220910.1.0 --artifact=qemu --arch=aarch64
# cosa decompress --build=37.20220910.1.0
# update tests/kola/upgrade/extended/test.sh with the patch
# cosa kola run --build=37.20220910.1.0 --tag extended-upgrade --append-butane tmp/target_stream.bu --debug
=== RUN   ext.config.upgrade.extended
--- PASS: ext.config.upgrade.extended (579.71s)
PASS, output in tmp/kola

[dustymabe]

hmm. are we sure at this point in the A -> B -> C upgrade case that B will always have the fixed OSTree? If so then this code is good, if not then we still need some of the previous logic that determines if B had the fixed OSTree.

[dustymabe]

ok I looked at some of the upgrade test logs from the most recent next stream's release and I think it's safe to not do the previous version check any longer because we'll always let zincati upgrade all the way to the latest release in the stream before doing the rpm-ostree rebase to the current build that we're testing.