Force a memory collection when the free memory is "low"

[palainp]

This PR is inspired by qubes-mirage-firewall. For each incoming and outgoing packets, it tests the free memory available, and if "low" (here <=40% of the total memory) it triggers a garbage collection.
Unlike qubes-mirage-firewall, there is nothing after to the garbage collection to get more memory.
In the dom0 logs, you can see that even a continuous ping decreases the free memory (from my point of view because of some cstructs in xenstore/etc.) :

[2024-06-24 08:29:10] 2024-06-24T06:29:10-00:00: [INFO] [application] Memory usage: free 10106432 / 24604672
[2024-06-24 08:29:20] 2024-06-24T06:29:20-00:00: [INFO] [application] Memory usage: free 10003184 / 24604672
[2024-06-24 08:29:30] 2024-06-24T06:29:30-00:00: [INFO] [application] Memory usage: free 9887840 / 24604672
[2024-06-24 08:29:40] 2024-06-24T06:29:40-00:00: [INFO] [application] Memory usage: free 13617776 / 24604672
[2024-06-24 08:29:50] 2024-06-24T06:29:50-00:00: [INFO] [application] Memory usage: free 13501536 / 24604672
...
[2024-06-24 08:34:10] 2024-06-24T06:34:10-00:00: [INFO] [application] Memory usage: free 10138656 / 24604672
[2024-06-24 08:34:20] 2024-06-24T06:34:20-00:00: [INFO] [application] Memory usage: free 10022704 / 24604672
[2024-06-24 08:34:30] 2024-06-24T06:34:30-00:00: [INFO] [application] Memory usage: free 9906336 / 24604672
[2024-06-24 08:34:40] 2024-06-24T06:34:40-00:00: [INFO] [application] Memory usage: free 13642208 / 24604672
[2024-06-24 08:34:50] 2024-06-24T06:34:50-00:00: [INFO] [application] Memory usage: free 13526288 / 24604672

The collection was able to get nearly 4MB of memory, and the second collection got the same amount a few minutes later.
To me, this will help to keep the amount of memory requested from Qubes by the unikernel as low as possible (the idea is that Linux is able to run with 400MB memory for network functions, and keeping unikernels an order of magnitude lower is good :) ).

[palainp]

Please note that the print free memory every 10 seconds is only for testing purpose and should be removed before merging (or the delay should be increased :) ).

[palainp]

Hmm the failure on hashsum is strange, I reproduced locally 3 times the same sha256 as in the PR, and I don't really know how/why there is another sha256 at CI :(

[palainp]

Ok, once again the fault lies between the chair and the keyboard :)
After deeply looking at the CI logs, I realized that I had left an unused and uncommitted .ml file, and had a bad local sha256, which has now been fixed.

[palainp]

With the new release of mirage-qubes, this PR is not relevant anymore (still need to wait for opam-repository integration). It will be easier to use the function provided upstream.