[#19] Support REST Api for sending configs and commands to devices (Device Communication API)

[gdimitropoulos-sotec]

Issue #19 is part of qualifying hono as a replacement for Google IoT Core customers (IoT Core is being retired in August 2023).
See also: eclipse-hono/hono#3441 & eclipse-hono/hono#3442

At this PR we have created the Device Communication API and the needed database table. At the moment the API is not able to communicate with the Hono command router and that will be achieved when the pub-sub communication is implemented in future PR.

Signed-off-by: g.dimitropoulos[email protected]

[calohmn]

Thanks for the PR.
As a general comment, before diving into the specifics of this component, it would be good if the added module here would adhere to the code style used in Hono. To add corresponding checks, you could add the corresponding maven plugin configurations

hono-extras/protocol-gateway/azure-mqtt-protocol-gateway/pom.xml

Lines 212 to 242 in 2be112b

	<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-checkstyle-plugin</artifactId>
	<version>3.1.2</version>
	<dependencies>
	<dependency>
	<groupId>org.eclipse.hono</groupId>
	<artifactId>hono-legal</artifactId>
	<version>${hono.version}</version>
	</dependency>
	<dependency>
	<groupId>com.puppycrawl.tools</groupId>
	<artifactId>checkstyle</artifactId>
	<version>10.2</version>
	</dependency>
	</dependencies>
	<executions>
	<execution>
	<id>checkstyle-check</id>
	<phase>verify</phase>
	<goals>
	<goal>check</goal>
	</goals>
	</execution>
	</executions>
	<configuration>
	<configLocation>checkstyle/default.xml</configLocation>
	<suppressionsLocation>checkstyle/suppressions.xml</suppressionsLocation>
	<includeTestSourceDirectory>true</includeTestSourceDirectory>
	</configuration>
	</plugin>

to the pom of the module. To do the corresponding local IDE setup, there is a chapter in the Hono documentation.

[calohmn]

When first testing the application and starting up without a corresponding database, this System.exit caused a deadlock ('Quarkus#blockingExit' was called on the main thread. This will result in deadlocking the application! [Error Occurred After Shutdown]). Using Quarkus.asyncExit(-1) instead would prevent that.

As a general note:
In the Hono components, the connection establishment to DB / messaging network components is decoupled from the (Quarkus) application startup. There are also retries being done. When a connection hasn't been established yet, the corresponding readiness check fails, in the Kubernetes context meaning the component isn't considered for incoming requests yet and is eventually getting killed if it keeps being not ready.
For the createDbClient method here, this would mean returning a Future<PyPool> instead. I'm still having a look at the overall structure here to get an idea of what else would need to be changed.

[gdimitropoulos-sotec]

I have replaced the system.exit with Quarkus.asyncExit.

[calohmn]

@gdimitropoulos-sotec Is #21 meant to replace this PR here?

[gdimitropoulos-sotec]

Hi @calohmn PR 21 adds the pub-sub functionality and is based on this PR here.

[gdimitropoulos-sotec]

@calohmn do you prefer to review this PR and after the 21 or should I create one PR for both?

[calohmn]

do you prefer to review this PR and after the 21 or should I create one PR for both?

Sorry for the delay. I've added a last set of comments. Then we can merge this.
(If you prefer, you could also go ahead with #21, abandoning this PR. On the other hand, it's good to have smaller PRs,
and as I've understood, #21 will need to wait for the upcoming Hono 2.4.0, so we can start with this PR here first.)

[gdimitropoulos-sotec]

Sorry for the delay. I've added a last set of comments. Then we can merge this. (If you prefer, you could also go ahead with #21, abandoning this PR. On the other hand, it's good to have smaller PRs, and as I've understood, #21 will need to wait for the upcoming Hono 2.4.0, so we can start with this PR here first.)

Thank you for your time. I have fixed all the issues from your comments and also update the other PR with these changes.

[calohmn]

LGTM, thanks for contributing.

[calohmn]

@gdimitropoulos-sotec As a follow-up, I've adapted the GitHub Actions workflow to also build the device communication API. I've also made some small adaptations/corrections - see c01bccb. This also includes choosing a generic application docker image name and setting the quarkus.container-image.build flag to false by default. I think it's better to let the user explicitly choose to build the docker image (like in Hono where an extra maven profile is used) and adapt the docker-registry/organization name along with that.