feat: Add vmlens checks

[chrfwow]

Adds a vmlens check to this repo. This tool will us in the future to find and fix concurrency issues in our code base.
VMLens works by attaching a Java agent during the test run, which will intercept calls inside the allInterleavings.hasNext() loop. The agent goes over all possible iterations of interleavings that threads could do, and thereby discoveres race conditions.

        try (AllInterleavings allInterleavings = new AllInterleavings("Concurrent evaluations")) {
            while (allInterleavings.hasNext()) {
                Runner.runParallel(
                        () -> assertEquals("def", client.getStringValue("a", "a")),
                        () -> assertEquals("as", client.getStringValue("b", "b")));
            }
        }

Asserts inside the tests help to verify that no operation was done on an intermediate state of the application.
Note that iterating over all interleavings can take some time, so the tests should be kept short.

The agent is installed by the vmlens-maven-plugin as needed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.24%. Comparing base (8dd40fa) to head (41b362e).

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1567      +/-   ##
============================================
+ Coverage     92.82%   93.24%   +0.42%     
- Complexity      487      489       +2     
============================================
  Files            46       46              
  Lines          1170     1170              
  Branches        103      103              
============================================
+ Hits           1086     1091       +5     
+ Misses           54       49       -5     
  Partials         30       30              

Flag	Coverage Δ
unittests	93.24% <100.00%> (+0.42%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[toddbaert]

I definitely think this is cool, and useful.

I have a concern about committing binaries though; to me, these always present a vector for attack in OSS projects, since it's very easy to miss changes to them and nearly impossible to verify their contents.

Could we instead download this files if they don't exist with dependency:get or maybe with maven-download-plugin or even a script (probably not he best option as it will break on windows)?

If you think I'm being overly worried here, please feel free to object. cc @aepfli @beeme1mr @lukas-reining

[chrfwow]

I agree with you, @toddbaert, having the binary in our code base is not optimal. If we choose to download the jar file during each build run, would you say we have to make sure that we check the integrity of the jar file by comparing it to some hash code, so that we can be sure the file wasn't tampered with?

[aepfli]

do we still need this ignore?

[chrfwow]

no. nice catch

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[chrfwow]

@toddbaert I removed the vmlens .jar file, because they are not needed. The vmlens-maven-plugin installs the agent on its own