chore: Pin build tooling

[dervoeti]

Description

Some build tooling is invoked without a pinned version, so it could change between two builds of the same image version. This could cause builds to break and also introduce malicious packages dependencies in the supply chain.
This PR pins or restricts it.

Maven:
mvn versions:set invokes the plugin by prefix. Unless the project POM pins it, Maven resolves the latest release on every build. It is now pinned to 2.22.0, the version that resolves today.

npm global installs:
The global installs (like cdxgen or yarn) pin the top-level version, but their transitive dependencies float.
I decided against vendoring lockfiles for these to keep it simple (we can do that once we have a good solution for Renovate updates) and just hardened the installation used two flags instead:

• --ignore-scripts: install scripts of the package and its dependencies no longer run. They are a common way npm malware executes.
• --before=<now - 7 days>: npm only resolves versions, including transitive ones, that were published at least 7 days ago, so a freshly published malicious version is not picked up before it is taken down.

As a consequence, a pinned version must be at least 7 days old, otherwise the install fails.

Superset npm:
nvm install --latest-npm installed whatever npm version was newest at build time. npm is now pinned via npm-version in boil-config.toml (10.9.9 for both versions, the newest release compatible with both Node versions) and installed with the same flags.

Definition of Done Checklist

Note

Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant.

Please make sure all these things are done and tick the boxes

• Changes are OpenShift compatible
• All added packages (via microdnf or otherwise) have a comment on why they are added
• Things not downloaded from Red Hat repositories should be mirrored in the Stackable repository and downloaded from there
• All packages should have (if available) signatures/hashes verified
• Add an entry to the CHANGELOG.md file
• Integration tests ran successfully

TIP: Running integration tests with a new product image

The image can be built and uploaded to the kind cluster with the following commands:

boil build <IMAGE> --image-version <RELEASE_VERSION> --strip-architecture --load
kind load docker-image <MANIFEST_URI> --name=<name-of-your-test-cluster>

See the output of boil to retrieve the image manifest URI for <MANIFEST_URI>.