Read-only container layer enforcement currently tracks which layers
have been mounted for each container. The state is being tracked
by maintaining a 2D slice of device targets and each slice represents
a potential overlay FS that can be used for a given container.
Index `i` in the Devices slice corresponds to container at index `i`
in the policy. For example for containers with the following hashes:
```
[
  [hash1, hash2, hash3],
  [hash1, hash4],
]
```
The corresponding Devices slice will look something like:
```
[
  [/mnt/target1, /mnt/target2, /mnt/target3],
  [/mnt/target1, /mnt/target4],
]
```

Each individual slice then corresponds to a potential overlay fs:
  - overlay1: `[/mnt/target1, /mnt/target2, /mnt/target3]`
  - overlay2: `[/mnt/target1, /mnt/target4]`

The issue arises when container contains duplicate layers like:
```
[
  [hash1, hash2, hash2],
  [hash1, hash4],
]
```
The potential overlays will be computed as following:
```
[
  [/mnt/target1, /mnt/target2, /mnt/target2],
  [/mnt/target1, /mnt/target4],
]
```
Instead of:
```
[
  [/mnt/target1, /mnt/target2, /mnt/target3],
  [/mnt/target1, /mnt/target4],
]
```
The issue is reproducable by the following Dockerfile:
```
FROM ubuntu:latest
COPY script.sh .
RUN chmod +x script.sh
```
where `script.sh` already has executable permission flag set.

To address the issue, the logic to track currently mounted devices
and enforcing the overlay has been updated.
Instead of tracking potential overlays, we track the devices that
have been mounted and their hashes:
```
{
  /mnt/target1: hash1,
  /mnt/target2: hash2,
  /mnt/target3: hash2,
}
```
During overlay, we map the mount targets to the hashes and check
the resulting hash chain against the ones in the policy.

Signed-off-by: Maksim An <[email protected]>

…ounted.

Signed-off-by: Maksim An <[email protected]>