Migrate tests depending on Boltkit to use Docker

[injectives]

Boltkit has been deprecated and requires additional setup on the host to run tests. This update migrates tests depending on Boltkit to use Docker that is needed for Testkit testing as well.

[michael-simons]

I tried running the full suite and it seems to work. org.neo4j.driver.stress.CausalClusteringStressIT however takes an awful lot of time.

In general, I am a big fan of getting rid of Boltkit, and having everything orchestrated from Maven. However, I was wondering why those tests are needed at all and wether they can't be orchestrated from Testkit rather than from the driver site. @robsdedude reminded me that Testkit can bring up concrete instances, too. And I am asking this as a big fan of Testcontainers/TestcontainersNeo4j.

+Edit+

I read this

The general plan is to migrate integration tests to Testkit, but there are many of them and it would take some time. In addition, not all manipulations are currently supported in Testkit.

And my question still applies: Do we need the manipulations from Testkits side or can't we just rely on getting the correct containers?

[injectives]

I tried running the full suite and it seems to work. org.neo4j.driver.stress.CausalClusteringStressIT however takes an awful lot of time.

Yes, CausalClusteringStressIT takes time. This update does not change this. We can look into putting it on a separate profile if we find this is necessary.

[injectives]

In general, I am a big fan of getting rid of Boltkit, and having everything orchestrated from Maven. However, I was wondering why those tests are needed at all and wether they can't be orchestrated from Testkit rather than from the driver site. @robsdedude reminded me that Testkit can bring up concrete instances, too. And I am asking this as a big fan of Testcontainers/TestcontainersNeo4j.

I think the tests are needed at least until we go over them and confirm that such cases are covered by Testkit. Those that are not covered will need to be migrated to Testkit and the ones that are covered will be decommissioned. During migration we usually determine if test case is better off tested with stub server or real one in Testkit.

This update simply lets us move away from deprecated Boltkit until we get to the steps described above.

[injectives]

And my question still applies: Do we need the manipulations from Testkits side or can't we just rely on getting the correct containers?

As far as I remember, Testkit does not currently support server state manipulations. For instance, stopping, starting, updating configuration or swapping ssl certificates. Some existing integration tests manipulate server state. Whether it makes sense to bring support to Testkit OR change test logic should be determined during migration to Testkit.