Support using the filesystem as backend for settings subsystem

[medarion]

Currently the code assumes that the settings subsystem always uses NVS. If this is not the case, the storage usage calculation is wrong.

This PR

• adds code that calculates the storage usage from filesystem info if CONFIG_SETTINGS_FILE is set
• disables compilation of nvs.h and nvs.c if CONFIG_SETTINGS_FILE is set, as it is not guaranteed that edgehog_partition or storage_partition exist in that case

I see a few options to further improve the PR:

• completely remove CONFIG_EDGEHOG_DEVICE_USE_EDGEHOG_PARTITION and the hardcoded partition selection and use DT_CHOSEN(zephyr_settings_partition) to deduce it directly from the zephyr,settings-partition device tree property
• perhaps send the storage utilisation of astarte_partition which is currently hardcoded in the Astarte device code
• reading the Edgehog docs it sounds as if the Storage Status endpoint should report general storage info. Then we could simply iterate over all mount points in the VFS and report all of them

What do you think?

[sorru94]

Rebase on master as we merged a fix to the formatting that was breaking the CI.

[sorru94]

Do not use single-character variables. Minimum is three chars according to our clang-tidy configuration.

[sorru94]

In general, this whole open close cycle intended to find the partition mount point should not be required.
Passing CONFIG_SETTINGS_FILE_PATH directly to fs_statvfs should work fine. I have not tested this myself, but looking at the codebase of Zephyr it seems to be used this way in multiple spots.
See, for example, the test test_file_statvfs.

[sorru94]

To answer the question in the body of the PR, this one looks good as a quick fix to support when the settings use a file system.
In the long term, I would convert the nvs.h file to a more generic storage.h header that exposes a generic edgehog_storage_get_free_space, placing your changes within its source code. But it can be done with a follow up.

The choice of reporting only the free space within the edgehog_partition was due to the complexity of fetching at runtime the information on all other partitions.

Edgehog can be added as a library to a project with an arbitrary number of partitions of different types. It results difficult to enumerate all partitions, inferring the type of each one, and then calculating how much free space they have. Even if we find a way to enumerate all the partitions present on the device and infer their type, we would still need to make sure there is no issue reading from them due to concurrent threads.

An idea could be to shift the control to the user by accepting a list of partition references with an associated type (and probably an access control structure to avoid access conflicts).

I have not looked into this myself, so I am not sure what the best approach would be.