The timestamp of the host-id is the timestamp of the secret_key file.
Under normal circumstances, reading the timestamp should never fail,
and reading it multiple times should always yield the same result.

If we unexpectedly fail to read the timestamp from the file we want:

- log a warning, so that the user can find out what's wrong. But
  do so only once.

- we don't want to handle errors or fail operation due to a missing
  timestamp. Remember, it's not supposed to ever fail, and if it does,
  just log a warning and proceed with a fake timestamp instead. In
  that case something is wrong, but using a non-stable, fake timestamp
  is the least of the problems here.
  We already have a stable identifier (the host-id) which we can use to
  generate a fake timestamp. Use it.

In case the user would replace the secret_key file, we also don't want
that accessing nm_utils_host_id_get_timestamp*() yields different
results. It's not implemented (nor necessary) to support reloading a
different timestamp. Hence, nm_utils_host_id_get_timestamp() should
memoize the value and ensure that it never changes.