fix: logback fix for NiFi / NiFi 2.6 build fix

[dervoeti]

Fixes: stackabletech/nifi-operator#856
Fixes: stackabletech/issues#779

Description

This PR contains two changes:

1. A fix to set the esbuild version to 0.25.10: For some reason, npm tries to use a newer version of esbuild than the version in the lock file. I suspect this might be related to how npm handles optional platform specific dependencies in lock files. I can't really say for sure though, and to avoid diving into the details of how npm works under the hood I chose the easier way by just setting esbuild to a fixed version, so our primary goal of getting back to a working build that uses the same packages as the original one is achieved. The esbuild version is set to 0.25.10 now to prevent npm from trying to select a newer version.

2. A patch for logback to prevent a race condition, this should fix the majority of problems mentioned in Corruption in nifi.log4j.xml nifi-operator#856

Smoke test for NiFi 2.4.0, 2.6.0 and 1.28.0 ran successfully.

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>.

[NickLarsenNZ]

Can confirm the corruption stops.

My test setup was to run a HandleHttpRequest and HandleHttpResponse pair of processor, and watch the logs:

tail -f nifi.log4j.xml | grep timestamp

Then rapidly curl the processor.

Before the fix, the corruption became quickly apparent. After the fix, I did the same test for longer and was not able to see any corrupted logs.

[NickLarsenNZ]

LGTM