anchor.diff:  <dramatic pause here>
   
   No, we don't want to scare you.
  -But are really going to switch to Java 17.
  -However, only for the tests.
  +We are actually planning to switch to Java 17, but only for the test suite.
   This will allow us to use more recent Java features in the tests, while users still can stay on Java 11.
   
   == Implementation
  
positive.code: Therefore if you want to run the tests with Java 11 (or 17), tests for Cassandra 3 module would fail.
  Obvious solution is to run Cassandra in a container with Java 8.
  This sounds good, but this approach has one pitfall.
  Cassandra connector needs access to Cassandra log files as it reads the dedicated log file to obtain CDC events.
  So the tests need to access Cassandra files in the container.
  This is still quite easily solvable by creating a temporary directory in e.g. `target` directory, giving it access to all users and bind-mounting it to the container.
  Cassandra running in the container can later on use this mounted volume for storing its data.
  The real issue starts when you try to do the cleanup after the tests.
  As Cassandra runs under dedicated user `cassandra` in the container, which is very likely not present on the test machine (or with different UID/GID), 
  cleanup fails when it tries to delete the temporary directory with Cassandra files.
  These files were created by a different user with insufficient rights for other users to delete them.
  Trying to delete them from Cassandra's container on Cassandra exit in some wrapper script turned out to be quite cumbersome and not very reliable.
  The most promising solution seemed to be to start another container with the same `cassandra` user after Cassandra container is stopped,
  bind-mount same directory there and delete all the files from this container.
  
  We considered two option for running containers:
  
  
negative.code: In the end, the decision was driven by the fact that running a cleanup container is not possible with the Fabric8 plugin.
  Maven doesn't allow to execute different configurations in the same phase 
  and therefore it's not possible to stop the Cassandra container in the `post-integration-test` phase and at the same time run cleanup container in this phase.
  Testcontainers allow starting and stopping containers programmatically when needed, 
  allows defining the images directly in code so we don't need any additional `Dockerfile`
  , and cleaning up the container is just an implementation detail hidden in the test itself.
  Having the ability to run the tests directly from the IDE is a nice benefit on top of these things.
  
  The only tricky thing when using testcontainers was that when we tried to remove the files using Docker `cmd` command,
  testcontainers randomly failed, stating that the container didn't start in spite of the fact that all Cassandra files were actually deleted.
  The container probably ran so fast that it finished before testcontainers noticed it.
  Finally, we solved it by adding a short `sleep` in the container and executing an additional command in the container which does the cleanup.
  
  The final cleanup code using testcontainers looks like this:
  
  