Resolve "File system expansion during runtime"

# Description

GekkoFS supports extending the current daemon configuration to additional compute nodes. This includes redistribution
of the existing data and metadata and therefore scales file system performance and capacity of existing data. Note,
that it is the user's responsibility to not access the GekkoFS file system during redistribution. A corresponding feature
that is transparent to the user is planned. Note also, if the GekkoFS proxy is used, they need to be manually restarted, after expansion.

To enable this feature, the following CMake compilation flags are required to build the `gkfs_malleability` tool: `-DGKFS_BUILD_TOOLS=ON`.
The `gkfs_malleability` tool is then available in the `build/tools` directory. Please consult `-h` for its arguments.
While the tool can be used manually to expand the file system, the `scripts/run/gkfs` script should be used instead which invokes the `gkfs_malleability` tool.

The only requirement for extending the file system is a hostfile containing the hostnames/IPs of the new nodes (one line per host).
Example starting the file system. The `DAEMON_NODELIST` in the `gkfs.conf` is set to a hostfile containing the initial set of file system nodes.:
```bash
~/gekkofs/scripts/run/gkfs -c ~/run/gkfs_verbs_expandtest.conf start
* [gkfs] Starting GekkoFS daemons (4 nodes) ...
* [gkfs] GekkoFS daemons running
* [gkfs] Startup time: 10.853 seconds
```
... Some computation ...

Expanding the file system. Using `-e <hostfile>` to specify the new nodes. Redistribution is done automatically with a progress bar. 
When finished, the file system is ready to use in the new configuration:
```bash
~/gekkofs/scripts/run/gkfs -c ~/run/gkfs_verbs_expandtest.conf -e ~/hostfile_expand expand
* [gkfs] Starting GekkoFS daemons (8 nodes) ...
* [gkfs] GekkoFS daemons running
* [gkfs] Startup time: 1.058 seconds
Expansion process from 4 nodes to 12 nodes launched...
* [gkfs] Expansion progress:
[####################] 0/4 left
* [gkfs] Redistribution process done. Finalizing ...
* [gkfs] Expansion done.
```
Stop the file system:
```bash
~/gekkofs/scripts/run/gkfs -c ~/run/gkfs_verbs_expandtest.conf stop
* [gkfs] Stopping daemon with pid 16462
srun: sending Ctrl-C to StepId=282378.1
* [gkfs] Stopping daemon with pid 16761
srun: sending Ctrl-C to StepId=282378.2
* [gkfs] Shutdown time: 1.032 seconds
```

# Results
IOR results for writing/reading 768 GiB sequentially (192 procs) before and after expansion

![image](/uploads/57bd8f3a07a56c496b1ae0b096da24ef/image.png)

MDTest results for creating, stating, removing, 19200000 (192 procs) before and after expansion

![image](/uploads/7e2f58d864789e657140ced3e9e9716e/image.png)

Closes #294

Closes #294

See merge request !196

Proxy must be restarted to know about the file system extension.

Resolve "PKG_CONFIG_PATH not propagated to dependency scripts"

Closes #286

Closes #286

See merge request !185

Resolve "Add system call: listxattr family"

Closes #287

Closes #287

See merge request !186

Resolve "Remove superfluous RPC during remove"

This MR improves remove() performance by avoiding one RPC. 

Before the change, the metadata of a path was fetched to check whether it is a directory or file. This is important because `rmdir()` and `unlink()` should not delete the wrong object. However, this meant that two RPCs were done per remove operation.

This update changes this behavior by checking the directory/file on the server during any remove operation. For this, an additional RPC field was added, which communicates whether the intent is to remove a directory. Overall, the semantics stay the same. The special case for `rename()` still requires the metadata check beforehand and is unchanged.

IO500 has shown that this optimization doubles throughput for latency-sensitive operations, i.e., zero-byte files or small files.

Depends on https://storage.bsc.es/gitlab/hpc/gekkofs/-/merge_requests/191

Closes #293

Closes #293

See merge request !195

New feature: GekkoFS Proxy

The GekkoFS proxy is an additional (alternative) component that runs on each client and acts as gateway between the
client and daemons. It can improve network stability, e.g., for opa-psm2, and provides a basis for future asynchronous
I/O as well as client caching techniques to control file system semantics.

The `gkfs` script fully supports the GekkoFS proxy and an example can be found in `scripts/run`. When using the proxy
manually additional arguments are required on the daemon side, i.e., which network interface and protocol should be
used:

```bash
<daemon args> --proxy-listen eno1 --proxy-protocol ofi+sockets
```

The proxy is started thereafter:

```bash
./gkfs_proxy -H ./gkfs_hostfile --pid-path ./vef_gkfs_proxy.pid -p ofi+sockets
```

The shared hostfile was generated by the daemons whereas the pid_path is local to the machine and is
detected by clients. The pid-path defaults to `/tmp/gkfs_proxy.pid`.

Under default operation, clients detect automatically whether to use the proxy. If another proxy path is used, the
environment variable `LIBGKFS_PROXY_PID_FILE` can be set for the clients.

Alternatively, the `gkfs` automatically sets all required arguments:

```bash
scripts/run/gkfs -c scripts/run/gkfs.conf -f start --proxy
* [gkfs] Starting GekkoFS daemons (1 nodes) ...
* [gkfs] GekkoFS daemons running
* [gkfs] Startup time: 2.013 seconds
* [gkfs] Starting GekkoFS proxies (1 nodes) ...
* [gkfs] GekkoFS proxies running
* [gkfs] Startup time: 5.002 seconds
Press 'q' to exit
```

Please consult `include/config.hpp` for additional configuration options. Note, GekkoFS proxy does not support
replication.

Closes https://storage.bsc.es/gitlab/hpc/gekkofs/-/issues/114

Closes #114

See merge request !191