Expose more monitoring information via pseudo-fs files

[wkozaczuk]

Even now some of the information (not necessarily monitoring) is presented using the procfs or fairly recently added sysfs filesystem (see 2835092 and 2847b2a). But a lot of such information is provided by the httpserver-api module and its read-only "cousin" - httpserver-monitoring-api which expose many HTTP endpoints returning information in JSON. There are some downsides to this approach:

• the httpserver-api is pretty tightly integrated with the internals of the OSv kernel and relies on many C++ symbols that need to be exported (see the related issue Adapt modules and unit tests to use C symbols instead of internal kernel C++ API #1186); we have recently made strides to at least convert some of those to the C symbols (see 182499c and fa3b38e) but many remain especially in the networking related libtools module
• thehttpserver-api is implemented in C++ so implicitly any image that wants to include this monitoring module AND wants to use the version of the kernel with most symbols and all C++ ones hidden, needs to add a fairly large libstdc++.so; it is even worse if the app is in C++ and needs a different version of libstdc++.so (see Combining pre-compiled OSv kernel with pre-compiled executable #821)

Where am I going with this? It would be nice to expose the information which currently httpserver-api retrieves by directly invoking C or still C++ symbols in form of the pseudo-files under /proc or /sys. The advantage of this approach is that any app even in Java would be able to read relevant pseudo-file and utilize it for monitoring. And httpserver-api does not need new endpoints to present new information - one could use the existing /file? endpoint to read the relevant pseudo file. In the future, we could implement an even smaller and "dummer" http module that would only know how to return the content of the files from /proc and /sys and allow for monitoring that way.

Obviously, we would want to use the standard Linux paths for at least some of this information, but if it is OSv specific enough, we would put those under /sys/osv/.