migration to java and to apicurio-registry repo

[famarting]

This testsuite is used for testing apicurio-registry and apicurio-registry operator in kubernetes/openshift, it's also being used to test productized versions of RedHat Service Registry.

This are the things I would do to rewrite this testsuite to the apicurio-registry repo:

• in apicurio-registry, integration-tests/testsuite/, integrate there a new testsuite model that manages the testing infrastructure in kubernetes/openshift
• testsuite have to support this types of testing infrastructure: local(by just using testcontainers or mocks) , kubernetes (kind,minikube,..) , openshift
• most likey some tests will support only k8s/ocp , that's fine, those tests won't be executed when running with local infra
• the k8s/ocp cluster have to be provided to the testsuite
• testsuite could require apicurio-registry-operator to run some tests (k8s/ocp and OLM testing), the operator manifests or version or OLM required info for OLM installation have to be provided to the testsuite
• testsuite can test operator + registry functionality together or just test the operator, applies to k8s/ocp
• regarding Debezium integration current golang testsuite has a test for that, that test uses the legacy Kafka Connect deployment model, currently there is a new deployment model, re-use debezium testsuite or do something by hand using the new model by leveraging AMQ Streams resources
• current golang testsuite has some old tests for specific usescases where it deploys specific infra to run some tests, things like keycloak... , this is not a hard requirement, but ability to run some tests with specific infra configurations will be needed

After that there is the task of updating all the CI jobs, we use GitHub Actions Workflows everywhere... for this you need to check:

• apicurio-registry workflows
• apicurio-registry-operator workflows

[famarting]

@obabec @Apicurio/developers JFYI