Commit 512fdb2 mistakenly used the value of total_inactive_file
from the top-level cgroup, thus the working set value was either
wrong (too low) or invalid (negative), for example:

> Unable to account working set stats: total_inactive_file (1572753409)
> memory usage (585728)" file="oci/oci_linux.go:93"

We need to use total_inactive_file and memory.usage_in_bytes from
the same cgroup, otherwise it does not make any sense.

While at it
 - promote the above message from debug to warning;
 - optimize getTotalInactiveFile() by using HasPrefix()
   rather than Contains().

Signed-off-by: Kir Kolyshkin <[email protected]>

It's done in a same manner as for v1, except for cgroupv2 there's no
total_* counters in memory.stat. My assumption is the counters now
include subcgroup counters, although I am only 95% sure about that
even after digging into the cgroupv2 docs.

Here's an emprirical way I used to check the above assumption:

	find /sys/fs/cgroup/system.slice/ -name memory.stat -type f \
		| xargs grep ^inactive_file 2>/dev/null \
		| awk '$2 > 0 {printf "%20d %s\n",$2,$1}' \
		| sort -nr

It shows that the top-level's cgroup value is higher than that of
sub-cgroups for both system.slice and user.slice.

PS I have also checked it is done the same way in containerd/cri.

Signed-off-by: Kir Kolyshkin <[email protected]>