Parameter `partition` wiederbelebt

* Wenn der Parameter gesetzt ist, schreibt das Gateway alle Nachrichten
  in die vorgegebene Partition.
* Wenn der Parameter null ist, wird die Default-Partitionierung
  (Hashing by Key) verwendet.

Initiale Version eines Gateways für die SumUp-Services

* Diese Version nimmt lediglich Anfragen per POST enggegen und schreibt
  sie in das Requests-Topic, das von dem Requests-Services ausgewertet
  wird.

Validierung für ApplicationProperties aktiviert

refactor: `RestProducer` wird explizit erzeugt

* `ApplicationConfiguration` eingeführt.
* Um eine bessere Kontrolle über die verwendeten Parameter zu erhalten,
  wird `RestProducer` jetzt explizit in `ApplicationConfiguration` erzeugt.
* `KafkaProducer` wird in `ApplicationConfiguration` erzeugt und in
  `RestProducer` hereingereicht.

Das Logging so überarbeitet/umkonfiguriert, dass man den Fehler sieht

Setup und README.sh für rest-producer überarbeitet

* Setup an das Ausgangs-Setup angeglichen.
* Das Setup verwendet jetzt `kafkacat` als Consumer.
* Das README.sh entsprechend der Übung und der Änderungen angepasst.

Später benötigten Konfiurations-Parameter `partition` hinzugefügt

Später benötigten Header zum Postmapping hinzugefügt

Merge der überarbeiteten Compose-Konfiguration ('endless-stream-producer')

Compose-Konfiguration unabhängig von Default-Konfiguration gemacht

* Damit Instanzen parallel über die IDE (mit voreingestelltem Default-Port)
  und Compose gestartet werden können, wurden den einzelnen Komponenten
  (Producer, Consumer etc.) jeweils unterschiedliche explizite
  Default-Ports zugewiesen.
* Dies führt leicht zu fehlern, in den Compose-Setups, da dort i.d.R.
  Port-Mappings für die gestarteten Instanzen definiert werden.
* Daher werden die Compose-Setups jetzt so umgestellt, dass sie den
  einkompilierten Default-Port der Komponenten explizit mit dem Port `8080`
  überschreiben, so dass alle Komponenten _innerhalb_ von Compose
  einheitlich (und so wie bei Spring-Boot standard) über `8080` ansprechbar
  sind.

Merge der Upgrades für Confluent/Spring-Boot ('endless-stream-producer')

Merge der Upgrades für Confluent/Spring-Boot (Branch 'first-contact')

Upgrade von Spring Boot und den Confluent-Kafka-Images

* Upgrade der Kafk-Images von Confluent 7.0.2 auf 7.1.3
** Unterstützt Kafka 3.1.x (siehe https://docs.confluent.io/platform/current/installation/versions-interoperability.html[Versions-Matrix])
* Upgrade für Spring Boot von 2.6.5 auf 2.7.2
** Enthält Kafka: 3.1.1
** Enthält Spring Kafka: 2.8.8

Name und Beschreibung in POM getrennt

Testfall, der die API aufruft und prüft, ob Nachrichten versendet werden

* Der Testfall verwendet `spring-kafka` als Abhängigkeit mit dem Scope
  `test`.
* Dies zeigt ein nicht zu unterschätzendes Anwendungsfeld für Spring
  Kafka, seblst wenn das eigentliche Projekt gar nicht auf Spring Kafka
  aufsetzt: Einfache Implementierung von Integration-Tests.

Info-Endpoint des Actuator korrigiert

* Der `kafka`-Eintrag hatte noch den veralteten Parameter `throttle-ms`
  des Endless Consumer enthalten
* Der `kafka`-Eintrag hatte noch nicht alle über `ApplicationProperties`
  konfigurierbaren Parameter ausgegeben.

Merge branch 'endless-stream-producer' into rest-producer

shutdown-Endpoint aktiviert

Informationen zur Kafka-Konfiguration im info-Endpoint sichtbar gemacht

Informationen zur Java-Umgebung im info-Endpoint aktiviert

Das Git-Commit-Id-Plugin generiert eine git.properties

Das Spring-Boot-Maven-Plugin generiert Build-Info

Default-Konfiguration überarbeitet

* Eine über die IDE bzw. Maven gestartete Instanz soll klar als solche
  erkennbar sein (`client.id` = DEV).
* Bisher gab es häufig Port-Konflikte, wenn über die IDE bzw. über Maven
  parallel zu einem Compose-Setup eine Instanz gestartet wurde. Daher wird
  jetzt hier explizit auf einen abweichenden Port (8880) ausgewichen.

Falschen Status-Code bei start/stop-Fehler korrigiert

Setup von counting-consumer auf endless-consumer umgestellt

* Da der Counting-Consumer von den Teilnehmern als Verbesserung des
  Endless-Consumer entwickelt wird, sollte dieser auch unter der selben
  Artefakt-ID abgelegt wird
* Ansonsten kommt es bei der Ausführung späterer Setups ggf. zu Fehlern,
  wenn diese weiterhin die Abweichende Artefakt-ID counting-consumer
  enthalten, obwohl folgende Verbesserungen wieder unter endless-consumer
  entwickelt wurden!

HTTPie gibt nicht nur den Response, sondern auch den Request aus

Merge des Upgrades der Confluent-Images auf 7.0.2

Merge des Upgrades der Confluent-Images auf 7.0.2

Upgrade der Images von Confluent 6.2.0 auf 7.0.2

Delivery-Timeout für den REST-Producer herabgesetzt

* Der Timeout für `delivery.timeout.ms` wurde von 2 Minuten auf 20
  Sekunden heruntergesetzt
* Grund: Die HTTP-Verbindungen der Clients laufen nach 30 Sekunden in
  den Default-Timeout, so dass die Fehler sonst nicht sichtbar werden!
* Achtung: Parallel musste dafür `request.timeout.ms` auf 10 Sekunden
  herabgesetzt werden, da `delivery.timeout.ms` größer oder gleich
  `request.timeout.ms` + `linger.ms` sein muss!
* Die 10s Spiel zwischen `delivery.timeout.ms` und `request.timeout.ms`
  werden für die Übungen benötigt, in denen mit `linger.ms` experimentiert
  werden soll...

Setup für die Demonstration des Rest-Producers überarbeitet

EndlessProducer in RestProducer umgearbeitet

* Der Producer nimmt die zu versendende Nachricht über ein POST entgegen
* Als Schlüssel wird der Pfad des POST-Aufrufs verwendet
* Die Anfragen werden mit einem DeferredResult asynchron verarbeitet
* Der Producer antwortet erst mit 200-OK, wenn die Nachricht bestätigt wurde
* Wenn der Broker mit einem Fehler antwortet, wird 500 zurückgegeben
* Wenn der Broker nicht erreicht werden kann, wird 400 zurückgegeben

EndlessProducer in RestProducer umbenannt

* Ohne die Umbenennung _vor_ der Veränderung würde die Versions-Historie
  der Klasse verloren gehen!

Korrekturen des README-Skriptes auf first-contact übernommen

README.sh verwendet den cli-Service für Kommandos

Fehlerkorrektur aus first-contact gemerged

Fälschlich hartkodiertes Topic gegen Variable getauscht

Verständliche Fehlermeldungen für DriverController

Synchronisation bei Start/Stop repariert und Ausgabe für Fehler ergänzt

Reorganisierten Code aus first-contact gemerged

SimpleProducer in Endless Producer umbenannt

* Nötig, um die GIT-Historie zu reparieren, so dass Änderungen über die
  Umbenennung hinaus von GIT erkannt werden können.

Code reorganisiert, um Änderungen vergleichbarer zu machen

Obsoletes Klassen-Attribut entfernt

Merge der Aktualisierungen aus first-contact

Upgrade für Spring Boot 2.6.0 -> 2.6.5

* Kafka: 3.0.1
* Spring Kafka: 2.8.4

Endless Producer: a simple producer, implemented as Spring-Boot-App

First Contact: Simple Producer & Consumer