Memory controller panics in some situations

[blt]

Describe the bug

In the lading project we're using cgroups-rs 0.3.4 to read memory and cpu controller data for processes in containers, managed with docker. We have discovered that unless --cgroupns host is set on the lading container lading will crash with a panic at this line. The problem does away if the host namespace is set, but it is unclear if the expected behavior is a panic or not from this crate.

Expected behavior

No panic, or a library function to determine if reads from the memory controller are valid or not prior to making a potentially panic'ing call.

Additional information

A backtrace from our project:

thread 'tokio-runtime-worker' panicked at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/cgroups-rs-0.3.4/src/memory.rs:587:34:
called `Result::unwrap()` on an `Err` value: Error { kind: ReadFailed("/sys/fs/cgroup/../docker-c73828602e1e6dc2514d805186a11769b03c72274355209b0b81885bf9da2cb4.scope/memory.high"), cause: Some(Os { code: 2, kind: NotFound, message: "No such file or directory" }) }
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: cgroups_rs::memory::MemController::memory_stat
   4: lading::observer::linux::Sampler::sample::{{closure}}
   5: lading::observer::Server::run::{{closure}}
   6: tokio::runtime::task::raw::poll
   7: tokio::runtime::scheduler::multi_thread::worker::Context::run_task
   8: tokio::runtime::task::raw::poll
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[krlohnes]

This PR looks like it would have fixed things, but stalled out.