CA-383852: Fix output from sar -A, move sar to cap(system-load)

[bernhardkaindl]

CA-383852: Fix a recently added feature:

Fix 'sar -A' from timing out:

The problem it solves was/is that the attempt to add the output of sar -A
(submitted from outside our team, just reviewed and merged by us) didn't work.

It appeared to work at back then, but when we test it now, we see that it timeouts.

This issue was that when the human-readable output of sar -A
was added in April to --entries=xenserver-logs, no timeout
for this capability was added, and the default timeout is -1:

This results in a nearly immediate timeout of any added command,
when the capability does is not defined with a specific max_time= parameter

• should we fix this?

To fix this, the reporter of the issue suggested that sar (a system load report) could be moved to a new capability.

Also, it should be noted that sar records are binary system load records, not XenServer specific log files:

Therefore, with this PR, I propose to create a new capability (system_load) to collect the sar data files (and the human-readable of output of sar -A) with a timeout of 30 seconds and a max_size of 70 MB.

I've set the personally identifiable information setting of system-load PII_MAYBE because of a private review comment (due to time pattern, maybe someone could make a guess based on activity data. That is definitely safe as the list of network interfaces and similar information is also currently set to MAYBE for other caps.).

# PII -- Personally identifiable information.  Of particular concern are
# things that would identify customers, or their network topology.
# Passwords are never to be included in any bug report, regardless of any PII
# declaration.
#
# NO            -- No PII will be in these entries.
# YES           -- PII will likely or certainly be in these entries.
# MAYBE         -- The user may wish to audit these entries for PII.
# IF_CUSTOMIZED -- If the files are unmodified, then they will contain no PII,
# but since we encourage customers to edit these files, PII may have been
# introduced by the customer.  This is used in particular for the networking
# scripts in dom0.

[GeraldEV]

Should we remove this max_size from the CAP_XENSERVER_LOGS to avoid growing the size of the status report?

[bernhardkaindl]

For CAP_SYSTEM_LOAD: The files in /var/log/sa which are collected in it now is ~33 MB (it keeps 60 binary in fixed binary format, so the size should not grow beyond that):

du -sch /var/log/sa
33M     /var/log/sa
33M     total

For CAP_XENSERVER_LOGS: Yes, I think not setting a max_size for CAP_XENSERVER_LOGS would simplify the code as it currently recalculates and updates its size, which may not be needed then. But we can keep that as it is now. If I understand this correctly, this can be done later when we clean up the code.