storage e2e test: remove race when setting up loopback device

CI has shown occasional failures stemming from an -EBUSY when
test/e2e/storage/persistent_volumes-local.go aka "PersistentVolumes-local"
attempts to do losetup.

Looking at the code, it has a clear race between querying the current
free loopback device and later explicitly attempting to loopback setup a
file at the queried device node.  Losetup nowadays includes the logic to
handle this for the user, if the '-f' option is used instead of naming
the desired target loopback device explicitly.  It is safe to presume
a suitable losetup is present as the '-f' option is used elsewhere in
the test, and it is safe to not record the allocated device, as it is
already queried on the fly elsewhere in the test ahead of other commands
which need to know an already created loopback device's node name.

This patch should result in less flakes for this test case.

Signed-off-by: Tim Pepper <tpepper@vmware.com>

test/e2e/storage/persistent_volumes-local.go

@@ -1324,9 +1324,8 @@ func createAndMapBlockLocalVolume(config *localTestConfig, dir string, node *v1.
 	mkdirCmd := fmt.Sprintf("mkdir -p %s", dir)
 	// Create 10MB file that will serve as the backing for block device.
 	ddCmd := fmt.Sprintf("dd if=/dev/zero of=%s/file bs=512 count=20480", dir)
-	losetupLoopDevCmd := fmt.Sprintf("E2E_LOOP_DEV=$(sudo losetup -f) && echo ${E2E_LOOP_DEV}")
-	losetupCmd := fmt.Sprintf("sudo losetup ${E2E_LOOP_DEV} %s/file", dir)
-	err := issueNodeCommand(config, fmt.Sprintf("%s && %s && %s && %s", mkdirCmd, ddCmd, losetupLoopDevCmd, losetupCmd), node)
+	losetupCmd := fmt.Sprintf("sudo losetup -f  %s/file", dir)
+	err := issueNodeCommand(config, fmt.Sprintf("%s && %s && %s", mkdirCmd, ddCmd, losetupCmd), node)
 	Expect(err).NotTo(HaveOccurred())
 }