machines: Robustify testAddDisk

[KKoukiou]

selectFromDropDown does not distinguish between options that one is substring
of the other thus choice can be random.

This commit is also part of #9240

I sent it also separately from the libvirt-dbus PR so that it's visible that testAddDisk failure it's not related to the aforementioned PR but this commit just uncovers the actual existing issue.

[KKoukiou]

testAddDisk failing with:

error: internal error: unable to execute QEMU command 'device_add': Failed to get "write" lock

is because of issue #9945 and not related to this change.

[martinpitt]

There's something wrong here. It's now by and large impossible to get this test to green. Either it fails due to the "write lock" (#9945) or it fails like here where apparently the same disk is added twice?

[martinpitt]

On my system (otherwise quiet) I can perfectly well and easily reproduce the Failed to get "write" lock failure, on fedora-28. It failed in 3 out of 3 cases.

[martinpitt]

Some debugging notes:

• I (locally, not pushed yet) added the same _temporary suffix to mydiskofpoolone, for the same reason. This makes no difference.
• I added a sit() right before the adding of mydiskofpooltwo_temporary to the VM (i. e. before the block that fails). Waiting for several minutes makes no difference, so this is not a race condition in that block.
• The file is not busy. The UI, virsh dumpxml, and # fuser /mnt/*/*all agree that the three other disks are busy (by the running qemu), but mydiskofpooltwo_temporary is not.
• The three files which are being used are owned by qemu:qemu (0600 perms), while mydiskofpooltwo_temporary is owned by root:root (0600 perms). This might explain the "write lock" error, as qemu is running as user qemu and cannot write that file. However, chowning it to qemu:qemu makes no difference, and after the failing test something changes mydiskofpooltwo_permanent to root:root. But I think the permissions are a red herring.

This really looks like libvirt gets confused. The debian-stable failure shows this - even though the test adds mydiskofpooltwo_temporary, the screenshot shows that it really seems to be mydiskofpooltwo_permanent again:

As a result, I disable this fourth test case for now. This is tracked in #9945.