Support inode resolution mechanism for Origin Detection

[wdhif]

Requirements for Contributing to this repository

• Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
• The pull request must only fix one issue, or add one feature, at the time.
• The pull request must update the test suite to demonstrate the changed functionality.
• After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see CONTRIBUTING.

What does this PR do?

Implements the support of Origin Detection when the container ID is unavailable from inside the container by using the inode resolution mechanic. The original Go implementation is here: DataDog/datadog-go#291

Description of the Change

If we are not able to find the container ID from inside the container, we will send instead the cgroup inode to be able to resolve the container ID on the Agent side.

Alternate Designs

Possible Drawbacks

Verification Process

Use the following deployment on a k8s cluster running cgroupv2:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dummy-dsd-python-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: dummy-dsd-python-app
  template:
    metadata:
      labels:
        app: dummy-dsd-python-app
        admission.datadoghq.com/enabled: "false"
    spec:
      containers:
      - name: dummy-dsd-python-app
        image: wdhifdatadog/dummy-dsd-python-app
        imagePullPolicy: Always
        env:
        - name: DD_AGENT_HOST
          valueFrom:
            fieldRef:
              fieldPath: status.hostIP

You should then be able to find a dummy.dsd.python.metric with a container_id tag.

Additional Notes

Release Notes

Review checklist (to be filled by reviewers)

• Feature or bug fix MUST have appropriate tests (unit, integration, etc...)
• PR title must be written as a CHANGELOG entry (see why)
• Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
• PR must have one changelog/ label attached. If applicable it should have the backward-incompatible label attached.
• PR should not have do-not-merge/ label attached.
• If Applicable, issue must have kind/ and severity/ labels attached at least.