RFE: SHM and/or FUSE to access nut-client information

[jimklimov]

In the 42ITy project there was a component to represent NUT and other readings as a virtual file system akin to /dev/shm for easier uniform access from other programs (and using entity names mapped to conform to tat project's standards).

This issue is about embracing a similar idea for NUT itself, to either have upsd represent an shm view for the local system (may require several OS-dependent implementations), and/or to make use of FUSE as an arguably more portable solution to wrap the abilities of libnutclient as a pure userland application (a mix of upsc, upsrw, upscmd) that might be able to use upsmon.conf (or a similar file) for privileged access to remote devices.

• consider R/W from root, maybe other user names?
• have a branch to view (or even edit?) configs, service/daemon states, etc. on local system (and maybe remote systems via some new daemon)?
• read-only just for pre-configured devices (a-la MONITOR in upsmon.conf) or any (a-la upsc whatever@wherever`)?
• https://www.kernel.org/doc/html/latest/filesystems/fuse.html
• https://en.wikipedia.org/wiki/Filesystem_in_Userspace
• https://en.wikipedia.org/wiki/Dokan_Library - sounds like FUSE for Windows!
• Consider https://en.wikipedia.org/wiki/GVfs as a role model?
• https://developer.ibm.com/articles/l-fuse/
• https://github.com/vi/execfuse (execfuse is a implement FUSE filesystems using a bunch of scripts. Consider it as a "shell FUSE binding") for PoC at least? => Introduce a simple PoC for NUT readings seen in FUSE file system #2592 and Address some warnings and code style vi/execfuse#14
• Maybe extend libcurl while at it? https://everything.curl.dev/internals/handler.html

This is loosely related to ideas about adding REST API to nut-cgi family out of the box, e.g. #2524, or extending upsc with a JSON/YAML printer - but note there are several third-party projects already implementing something of the sort (with a downside of often requiring a further execution environment like NodeJS or Python, while a NUT-specific solution could be a standalone binary, friendlier to embedded use-cases). Maybe a single daemon could handle queries for both file-system access and CGI/RESTAPI given the path-based similarities?..

Sounds like a fun project, design and PRs would be welcome.

CC FYI: @arnaudquette-eaton

Reminded me of an unrelated idea in issue #1950 (kernel modules for systems whose life-cycle can not use a nutshutdown kind of script directly) that is somewhat similar in terms of OS-dependent development that can benefit tighter NUT integrations (especially for complex shutdowns).