chore: Remove Node.js 16 support

[lym953]

What does this PR do?

1. Deletes tests for Node.js version 16. Keep 18 and 20.
2. In build.yml and integration_tests.yml workflows, change Node.js version from 16 to 18.

Motivation

1. From the annoucement Bringing forward the End-of-Life Date for Node.js 16, the End-of-Life Date for Node.js 16 is September 11th, 2023. I think it's okay for us to no longer support it.
2. The latest version of some dependencies are no longer compatible with Node.js 16. For example, if I upgrade projen to the latest version, then projen will update the devDependency: "@typescript-eslint/eslint-plugin": "^6", to ^7, and the v7 doesn't work with Node 16. As a result, I can no longer upgrade projen. This blocks the fix of PEP 625 compliance for Python distribution.

Testing Guidelines

Pass other existing tests.

Additional Notes

Types of Changes

• Bug fix
• New feature
• Breaking change
• Misc (docs, refactoring, dependency upgrade, etc.)

Check all that apply

• This PR's description is comprehensive
• This PR contains breaking changes that are documented in the description
• This PR introduces new APIs or parameters that are documented and unlikely to change in the foreseeable future
• This PR impacts documentation, and it has been updated (or a ticket has been logged)
• This PR's changes are covered by the automated tests
• This PR collects user input/sensitive content into Datadog

[avangelillo]

Do we have any metrics to indicate if anyone is still on node 16? If someone is, will this break them?

[datadog-datadog-prod-us1]

🟠 Code Vulnerability

Workflow depends on a GitHub actions pinned by tag (...read more)

When using a third party action, one needs to provide its GitHub path (owner/project) and can eventually pin it to a Git ref (a branch name, a Git tag, or a commit hash).

No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state.

Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks.

Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.