[omnibus] Patch psutil to fix automount logs in Docker container with disk check

[KSerrania]

What does this PR do?

Adds an omnibus patch to psutil to fix an issue with that started with the 5.7.4 release of psutil.

Motivation

In Agent 7.35.0, we upgraded the embedded psutil version from 5.7.2 to 5.9.0. One of the changes this brought is giampaolo/psutil#1863, which modified psutil.disk_partitions to also collect the maxpath and maxfile fields.

This new feature has two negative effects:

• it negatively impacts the performance of the psutil.disk_partitions (mentioned in Allow to avoid expensive statfs call in disk_partitions. giampaolo/psutil#2110)
• on systems where automount is enabled, if you run the Docker Agent with the disk check enabled and /proc mounted in the container (which is what we document in our install docs), the automount of binfmt_misc is repeatedly called, causing a huge amount of noise in /var/log/syslog (during each check run):

Jul  1 11:47:17 ubuntu-bionic systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 5809 (agent)
Jul  1 11:47:17 ubuntu-bionic systemd[1]: proc-sys-fs-binfmt_misc.automount: Automount point already active?
Jul  1 11:47:17 ubuntu-bionic systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 5809 (agent)
Jul  1 11:47:17 ubuntu-bionic systemd[1]: proc-sys-fs-binfmt_misc.automount: Automount point already active?
Jul  1 11:47:17 ubuntu-bionic systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 5809 (agent)
Jul  1 11:47:17 ubuntu-bionic systemd[1]: proc-sys-fs-binfmt_misc.automount: Automount point already active?
Jul  1 11:47:17 ubuntu-bionic systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 5809 (agent)
Jul  1 11:47:17 ubuntu-bionic systemd[1]: proc-sys-fs-binfmt_misc.automount: Automount point already active?
Jul  1 11:47:17 ubuntu-bionic systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 5809 (agent)
Jul  1 11:47:17 ubuntu-bionic systemd[1]: proc-sys-fs-binfmt_misc.automount: Automount point already active?
Jul  1 11:47:17 ubuntu-bionic systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 5809 (agent)
Jul  1 11:47:17 ubuntu-bionic systemd[1]: proc-sys-fs-binfmt_misc.automount: Automount point already active?

This PR patches psutil to remove the maxpath and maxfile fetch feature, which we don't use in the check.

Once giampaolo/psutil#2110 is merged and released, we can remove this patch, update psutil and add the get_maxfile_maxpath=False option to the disk check's psutil.disk_partitions calls.

Additional Notes

The issue can be reproduced by rebooting the host, then running:

sudo docker run --rm -d --name dd-agent -e DD_API_KEY="<api key>" -e DD_LOG_LEVEL=DEBUG -e DD_SITE="datadoghq.com" -e HOST_PROC=/host/proc -e DOCKER_HOST=unix:///var/run/docker.sock -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro gcr.io/datadoghq/agent:7.35.0

on an Ubuntu system (I tried with 18.04).

The fix can be tested by rebooting the host again, then running:

sudo docker run --rm -d --name dd-agent -e DD_API_KEY="<api key>" -e DD_LOG_LEVEL=DEBUG -e DD_SITE="datadoghq.com" -e HOST_PROC=/host/proc -e DOCKER_HOST=unix:///var/run/docker.sock -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro docker.io/datadog/agent-dev:nightly-a04d0739-py3

Possible Drawbacks / Trade-offs

n/a

Describe how to test/QA your changes

Run the setup described in the additional notes, check that the issue happens with 7.35.0 ~ 7.37.1 but not with this PR, and that the disk check works as expected.

Reviewer's Checklist

• If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
• Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
• A release note has been added or the changelog/no-changelog label has been applied.
• Changed code has automated tests for its functionality.
• Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
• At least one team/.. label has been applied, indicating the team(s) that should QA this change.
• If applicable, docs team has been notified or an issue has been opened on the documentation repo.
• If applicable, the need-change/operator and need-change/helm labels have been applied.
• If applicable, the config template has been updated.

[amenasria]

LGTM

[hestonhoffman]

No docs review required