If the lockfile directory gets removed but the container runtime is
still running with an open storage instance, then we can trigger a
runtime panic by:
1. Starting CRI-O
2. Removing the lockfile dir, e.g.:
`sudo rm -rf /var/lib/containers/storage/overlay-images`
3. Running `crictl images`
```
panic: error opening "/var/lib/containers/storage/overlay-images/images.lock": no such file or directory
goroutine 93 [running]:
github.com/containers/storage/pkg/lockfile.(*lockfile).lock(0xc0006b83c0, 0x2000000)
/go/src/github.com/cri-o/cri-o/vendor/github.com/containers/storage/pkg/lockfile/lockfile_unix.go:107 +0x388
github.com/containers/storage/pkg/lockfile.(*lockfile).RLock(0xc0006b83c0)
/go/src/github.com/cri-o/cri-o/vendor/github.com/containers/storage/pkg/lockfile/lockfile_unix.go:146 +0x37
github.com/containers/storage.(*imageStore).RLock(0xc00006e420)
/go/src/github.com/cri-o/cri-o/vendor/github.com/containers/storage/images.go:778 +0x33
github.com/containers/storage.(*store).Images(0xc0003f3b80, 0x0, 0x0, 0x0, 0x0, 0x0)
/go/src/github.com/cri-o/cri-o/vendor/github.com/containers/storage/store.go:3089 +0x1dc
```
We now ensure the parent lockfile directory, but only if it does not
exist to not degrade the performance of c/stroage.
Unit tests around that case have been added as well.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
Sascha Grunert