Remove sin & sout states from system.swap.* if they can not be computed

[dabico]

Description

Changes:

• Default and user-specified instances of configuration dictionaries are now deeply copied when passed to SystemMetricsInstrumentor.
• On macOS, if the user-specified config contains system.network.connections, then the metric will be removed and a warning is logged.
• On Linux, if the user-specified config contains system.swap.usage or system.swap.utilization, the sin and sout states will be removed from both metrics and a warning is logged.
• Any RuntimeWarning emitted by psutil is (narrowly) suppressed whenever psutil.swap_memory is called in gauge callbacks.

Fixes #3740

Type of change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Added a dedicated test for this functionality:

instrumentation/opentelemetry-instrumentation-system-metrics/tests/test_system_metrics.py::TestSystemMetrics::test_system_swap_states_removed_when_vmstat_missing

Ran it against several Python versions as follows:

tox -e py39-test-instrumentation-system-metrics
tox -e py310-test-instrumentation-system-metrics
tox -e py311-test-instrumentation-system-metrics
tox -e py312-test-instrumentation-system-metrics
tox -e py313-test-instrumentation-system-metrics

Note that it's set to only run on Linux.

Does This PR Require a Core Repo Change?

No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: dabico / name: Ozren Dabić (0e8e68f, 9431692, d8facf6, fc878a6, 4753b38, dbb81e0)

[dabico]

Spending some more time with the code, I came to the realisation I over-compensated with the metric removals. The error message states that sin and sout can't be computed, but these two states aren't part of the _DEFAULT configuration. A more desirable course of action would be to remove these two states from the passed config and issue a log warning if the trigger conditions are met. Will rework this.