feat: Add restic and OS details to system info

[inode64]

When managing multiple systems, it's important to know where I'm connected, the version of backrest, and the OS.
I've included the uptime information because I've occasionally experienced issues with the server rebooting. This way, I know how long backrest has been active.

And it has also happened to me that the DataPath directory grows excessively and fills all the space, so you can control how much it is being used

[garethgeorge]

Broadly looks great, thanks for the interest in contributing the extra details. Left a few nits. Only summary detail I have some reservations about is the storage used mostly from a performance perspective.

Overall appreciate the extra details -- agree that this will help users with differentiating installs and keeping track of uptime for noticing crashes (which I think are very rare) is a nice addition.

[inode64]

Yes, I understand the problem this could pose.
Also, now that I'm not really seeing the serial dataDir, what worries me most is the rapid growth. I see that it's between 8 and 12 MB.
The restic cache, which in some cases exceeds 4 GB.
I'm thinking of something more optimised; otherwise, I'll deactivate it.

[garethgeorge]

Hmm, I was thinking on this a bit longer -- we can probably leverage the summary dashboard's refresh logic for a decent solution, see

backrest/webui/src/views/SummaryDashboard.tsx

Line 78 in 3ccb883

const interval = setInterval(fetchData, 60000);

What if we do the following

1. Add an additional once off refresh after ~5s on the first load of the page.
2. On the first request to the summary dashboard trigger updating slow properties e.g. the restic version, data directory size, etc in the background. Compute these once and cache them (either forever, or to be refreshed only after some TTL). But return immediately w/a partial response if they aren't ready in the cache.

In this way, the first request will load fast, the second request follows up with slow to compute data.

[inode64]

I've removed the space calculation as it can be a performance penalty.
I'll think about the best way to do it for another pull request.

[garethgeorge]

This one is quite slow as well-- let's defer it to the future PR as well, with that change I think this LGTM to merge!