tests: Determine initial version from filename

[mkalcok]

Upgrade tests need to determine the initial MicroOVN version so that it can be deployed, and then upgraded to the MicroOVN built from source. This verifies that the upgrade path is possible.

This initial version was previously controlled by env variable MICROOVN_SNAP_CHANNEL, but the limitation was that in a single run, we could define only one set of upgrade tests (from MICROOVN_SNAP_CHANNEL to currently built).

This change introduces a mechanism to determine the initial MicroOVN version based on the test filename instead. With this approach, we can create multiple symbolic links (e.g. upgrade_22.03.bats -> upgrade.bast, upgrade_24.03.bats -> upgrade.bats) to trigger multiple parallel upgrade tests.

Upgrade tests with the original/generic name (e.g. upgrade.bats) will upgrade from the version that's in the default channel for the MicroOVN snap.

---

Some general thoughts/discussion:
Every branch, main, branch-22.03, branch-24.03 will have to have a different set of upgrade tests.

For branch-22.03 we will:

• backport this change
• replace upgrade.bats with upgrade_22.03.bats
  This will ensure that any change backported to branch-22.03 will test upgrade against 22.03/stable channel

For main branch we'll keep only the upgrade.bats file. This ensures that whatever goes to main branch (as eventual successor to the current default channel), will be tested against whatever is currently default MicroOVN. We can not add something like upgrade_22.03.bats to the main branch because we'll eventually build MicroOVN based on OVN 24.09 (and later), and that won't be compatible for upgrade from 22.03.
Also, since the main will become the development of 26.03, we do not have to keep direct backward compatibility with 22.03, only with 24.03.

For branch-24.03 we will keep only upgrade.bats for now. Once the 24.03/stable channel is released, we will:

• remove upgrade.bats
• add upgrade_22.03.bats
• add upgrade_24.03.bats
  This will ensure that whatever we backport to branch-24.03 will be tested for upgrade with 22.03/stable and 24.03/stable.

I know this sounds like a lot, but after the initial setup, all we need to do in future releases is, at the point of publishing new stable channel, replace upgrade.bats with upgrade_<current_LTS>.bats and upgrade_<previous_LTS> in the corresponding branch.

[fnordahl]

Thanks for this, @mkalcok!

It does indeed become a little forest of symlinks, but that aligns with our current setup and I also like the explicit nature of it.

If we find it too tedious, we could in the future attempt to determine the last two tracks relative to our current branch version or something like that.

Something like:

current_track=5.19
snap info lxd | \
    awk '/[[:digit:]]\/stable/{split($1,channel,"/"); print channel[1]}' | \
    sort -nr | \
    grep -A2 $current_track | \
    tail -2