readlink write at most PATH_MAX, thus we need to support also the worst case
scenario in which all the bytes are written.

ensure rpc_addresses object have been initialized before we use it for
the first time

Instead of passing only the mode as paramenter, we now pass an entire
Metadata object in such a way that the parameter can be configured at
compile time. For instace if we support symlinks we would like also to
pass the target path

the functionality wasn't used at all and it will be implemented later
with a different approach

this patch was resolving the 100% CPU bug [1]

But it was also introducing invalid read inside mercury library. Thus
from time to time it could led to segmentation faults.

[1]: https://github.com/mercury-hpc/mercury/issues/229

Can be used to retrieve the Metadata object for a named path

In several places the adafs_stat function have been replaced with this
new adafs_metadata. This allowed to avoid the construnction of the
additional `struct stat`.

This allowed to avoid improper static_cast to check downcasting

Metadata class needs to be used by both the client and the daemon

The metadata class needs to represent metadata of a file,
thus it shouldn't contain the path itself. In fact we actually didn't
use it at all.

This will make further refactoring easier and it save some memory copies.

when unlinkat was called with a link we were removing the target and not
the link itself

In the kernel VFS some file descriptors under /proc/<PID>/fd/ could be
links to a pipe, this is a special case in which the `readlink` function
would not work. So when we detect this case we forward to kernel

when resolving path we don't want always
to resolve also the last components if it is a link. Cause in some cases
we want exactly the path of that link and not the one it points to.

lstat and readlink are some example of functions that don't want to
resolve the last link.