feat: custom version for Kafka

[dervoeti]

Description

Part of #1068

This PR enables custom versions (with a suffix like -stackable0.0.0-dev) for Kafka.

In the SBOM, the custom version is replaced by the original one (using sed), so vulnerabilities filed directly against Kafka are still detected by scanners when scanning the SBOM.

I built Kafka 3.9.0, tested it with the smoke test and manually validated that it reported the correct version.

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:

bake --product <product> --image-version <stackable-image-version>
kind load docker-image <image-tagged-with-the-major-version> --name=<name-of-your-test-cluster>

See the output of bake to retrieve the image tag for <image-tagged-with-the-major-version>.

[razvan]

Have you thought of any possibility to integrate the version patching in patchable?

This would ensure reproducibility outside the docker build and allow for a dev to check that the version update is actually correct.

[dervoeti]

Have you thought of any possibility to integrate the version patching in patchable?

This would ensure reproducibility outside the docker build and allow for a dev to check that the version update is actually correct.

I thought about that as well, but didn't find a good solution yet. But now that I think about it again... I could create a patch file that appends -stackable0.0.0-dev to all the versions and then replace that placeholder with -stackable${RELEASE} before building Kafka. Maybe that's better, it would still require replacing before running Gradle, but could just replace -stackable0.0.0-dev across all files. So at least we'd have separate patch files for each Kafka version which adapt the original version in different source files (which files exactly can depend on the Kafka version), that would be an improvement. Currently the files that get changed are static for all Kafka versions. And you get the final source code for the dev build when running patchable checkout.
I could implement that, I think it would improve things.

[razvan]

I could implement that, I think it would improve things.

So do you still want this PR merged as is first?

[dervoeti]

I could implement that, I think it would improve things.

So do you still want this PR merged as is first?

No, I'll adapt it later today

[dervoeti]

@razvan I updated the process now, seems to work

[razvan]

lgtm assuming the hive patch in this pr was intentional :)

[dervoeti]

lgtm assuming the hive patch in this pr was intentional :)

The Hive patch was already merged in main, I just rebased it into this PR