Initial limited support for direct connections

[rhauch]

Summary of Changes

Resolves #96

This adds the initial but limited support for a new type of connection resources, called DIRECT connections, that represent a local or remote Kafka cluster and/or Schema Registry. The extension might create a direct connection to talk to a locally running CP installation, or a remote Apache Kafka cluster with a remote Schema Registry, or even a CCloud cluster with Schema Registry. The user may have to provide credentials to successfully authenticate and connect to each remote service/cluster.

The direction connections are not necessarily the constructs we want to expose. It is likely that near-term versions of the VS Code extension will allow users to connect to local or remote Kafka and SR clusters, but it may also expose to users different kinds of connections that are all represented in the sidecar as direct connections. For example, maybe the VS Code extension allows users to connect to “Confluent Platform”, “Apache Kafka”, and “WarpStream” (in addition to CCloud and local AK+SR), and these might all be customized facades on top of direct connections.

This is the first step in full support for direct connections, and as such only limited functionality is available in this PR:

• CRUDL connection resources with type=DIRECT, with validation of fields for each type of connection.
• A direct connection contains zero or one kafka_cluster object and zero or one schema_registry objects, allowing it to connect to a (remote or local) Kafka cluster and/or a (remote or local) Schema Registry.
• GraphQL support for the Kafka cluster and SR referenced by direct connections.

Once this PR is merged, the following will handled as followups to complete the support for direct connections:

• 123

• 124

• 125

• 126

• 127

After that, we will have more improvements to better support Confluent Platform:

• 128

Other improvements may include:

• 129

• 130

• Allow direct connections to connect to Flink cluster and Kafka Connect cluster.

Also, we avoided using javax and instead used jakarta imports due to the transfer of Java EE to the Eclipse Foundation, where it became Jakarta EE. The older javax packages within Java EE have been deprecated. Jakarta EE uses the jakarta namespace, which is incompatible with the legacy javax namespace. Mixing the two can cause issues. Several projects and frameworks… have already adopted Jakarta. Additionally, upgrading to Jakarta allows you to keep up with the latest changes and modernize your applications.

https://github.com/jakartaee/platform/blob/main/namespace/mappings.adoc#mapping-javax-to-jakarta

Pull request checklist

Please check if your PR fulfills the following (if applicable):

• Tests:
  • [x] Added new
  • [x] Updated existing
  • [x] Deleted existing
• [x] Have you validated this change locally against a running instance of the Quarkus dev server?

  make quarkus-dev

• [x] Have you validated this change against a locally running native executable?

  make mvn-package-native && ./target/ide-sidecar-*-runner

[rhauch]

Waiting for final approval from @flippingbits, since they had some questions.

[rhauch]

112 was recently merged. Locally, I did the following to verify main builds with this PR branch:

$ git pull origin main
$ git checkout direct-connect
$ git merge main
$ make clean build test mvn-package-native

All is good, and I did some basic testing with the native image, confirming that the Connections API works as expected for local, CCloud and the new direct connections. The local and CCloud connections should not be affected by this PR build, other than validating create and update of connection resources, which have good coverage with new tests.

Based upon this, I'm merging this PR.