Batching zeitnah versendeter Nachrichten ermöglicht

* Durch den Aufruf der blockierenden Methode `get()` wurde erzwungen, das
  der Versand einer Nachricht von Kafka bestätigt wurde, bevor die
  nächste Nachricht an Kafka übergeben werden konnte.
* Der blockierende Aufruf wurde jetzt in eine getrennte asynchrone
  Verarbeitung (in dem Default-Thread-Pool) verschoben.
* Dadurch können jetzt mehrere für den Versand bereitgestellte Nachrichten
  hintereinander an Kafka übergeben werden.
* _Beachte:_ Der Effekt wird erst dann wirklich deutlich, wenn das
  Throttling über `Thread.sleep(500)` deaktiviert wird!
* _Beachte:_ Da die Verarbeitung der Rückmeldung von Kafka über den
  Default-Thread-Pool erfolgt, erfolgt die Erzeugung der Log-Ausgaben
  asynchron in verschiedenen Threads. D.h., die Log-Meldungen werden
  _nicht_ in der Reihenfolge ausgegeben, in der die Nachrichten versendet
  wurden, was auf den ersten Blick sehr verwirrend ist!

Die begrenzte Queue mit Blocking wird nicht mehr benötigt

Fehler korrigiert: Shutdown wartet auf Versand der wartenden Nachrichten

* Über die Verwendung einer Semaphore wird sichergestellt, dass alle
  für das Queuing übergebenen Nachrichten auch an Kafka übergeben werden,
  bevor `KafkaProducer.close()` aufgerufen wird
* Ansonsten wurden geschedulte Nachrichten teilweise erst an den Producer
  übergeben, nachdem dieser bereits geschlossen wurde, so dass es zu
  Fehlern gekommen ist.

Fehler korrigiert: Erhalt der Sendereihenfolge trotz `supplyAsync()`

* Für die Ausführung wird jetzt ein Executor mit nur einem Thread verwendet
* Dadurch ist sichergestellt, dass die Reihenfolge erhalten bleibt

Log-Meldung für das Queuing der Nachricht ergänzt

Ergebniskontrolle über das zurückgegebenen Future<RecordMetadata>

Limits für die Definition des Service `producer` ergänzt

* Dadurch wird die Gefahr eingegrenzt, dass der Arbeitsplatz eines TN
  überlastet wird.
* Dies ist einigen TN passiert, weil sie den `ExampleProducer` ohne
  `Thread.sleep(500)` als Image gebaut haben.
* Wenn dieser dann unbedacht im Hintergrund weiterläuft, kann das den
  Rechner schnell lahm legen...

Eindeutigere Benennung der erfassten Zeitstempel

Upgrade von Spring-Boot 3.4.1 -> 4.0.2 (grundlagen/simple-producer)

Der Producer zählt statt der gesendeten Nachrichten die in der Queue

Fehlermeldung & Abbruch anstatt hartkodierter Standard-Konfig

Einrückung so, wie es IntelliJ will...

`build.gradle` so erweitert, dass das Image gebaut werden kann

Gradle-Wrapper entfernt

Gradle-Konfiguration für Version 8.11.1 hinzugefügt (mit Wrapper!)

Lombok benötigt nur den Scope `compile`

Maven-Wrapper wieder entfernt - Stört Firewalls beim verschicken

Partition & Offset stehen eindeutig in der Log-Meldung

Logmeldungen verwenden Methodenparameter, wo möglich

Maven-Wrapper von Spring-Boot ergänzt und `README.sh` angepasst

Spring-Boot auf 3.4.1 aktualisiert

Bei einem unerwarteten Fehler wird auch der Stacktrace mit ausgegeben

Der Nachrichten-Wert wird in allen Log-Meldungen mit ausgegeben

Logging-Pattern überarbeitet

Unnötige Kommandos aus der `README.sh` entfernt

`docker` in `simple-producer` verwandelt`

CPU/Memory-Limits in dem Setup für Docker-Compose ergänzt

Setup für Docker von COMBINED auf ISOLATED (mit einem Controller) umgestellt

Setup für Docker Compose auf Image `apache/kafka` und KRAFT umgestellt

Fehler im Docker-Setup: log.interval.check.retention.ms war uneinheitlich

Schema-Registry & Connect aus dem Setup für die Grundlagen entfernt

Zoonavigator aus dem Docker-Setup entfernt

Kafka-Images auf 7.8.0 aktualisiert

`log.retention.check.interval.ms` auf 10 Sekunden gesetzt

``version``-Eintrag in `docker-compose.yml` entfernt

"Final Newline" in `.editorconfig` gefordert (scheint vim zu entsprechen)

`.gitignore` und `.editorconfig` hinzugefügt

Schreibweise des CLI-Kommandos für Docker-Compose korrigiert

Upgrade der verwendeten Kafka-Images auf 7.7.1

ZooNavigator in den Demo-Stack aufgenommen

`README.sh` bricht ab, wenn `setup` nicht erfolgreich ist!

Start von Service `setup` startet auch `cli`

Der Service `setup` wartet bereits auf den Cluster

Grace-Period für Broker und cli/setup gesetzt

Schönere YAML-Syntax für `setup`-Service

Services `schema-registry` und `connect` hinzugefügt

Hilfs-Services `setup` überarbeitet

Volumes für die Log-/Config-Daten und Zookeeper hinzugefügt

Setup zurück auf Confluent (Version 7.5.1) mit Zookeeper umestellt

AKHQ auf einen eindeutigeren Port verlegt

Automatisches entfernen von Orphans beim Start

Docker-Setup in das Unterverzeichnis `docker` verschoben

Docker-Setup auf `bitnami/kafka:3.4` aktualisiert und vereinfacht

* Die Konfiguration musste an (undokumentierte?!) Änderungen in der
  version 3.4 von `bitnami/kafka` angepasst werden.
* Die drei Broker spielen jetzt gleichzeitig Controller. D.h., der
  Service `kafka-0`, der explizit Controller gespielt hat, fällt weg.

Bedienbarkeit des Setups verbessert

* Setup starten mit `docker-compose up -t0 -d cli`
** Dabei wird _nicht_ automatisch das Topic `test` neu angelegt
** D.h., die Daten gehen nicht unbeabsichtigt verloren, wenn man mit
   `up -d` prüft, ob noc alles läuft!
* Das Topic `test` kan mit `docker-compose restart -t0 setup` explizit
  gelöscht und neu angelegt (aka geleert) werden.

`docker-compose up setup` startet auch die cli

AKHQ zu dem Basis-Setup hinzugefügt

Compose-Setup auf bitnami mit KRAFT umgestellt

* Setup aus Unterschied zu `spring-consumer--json--adder` übernommen.
* Auch das `README.sh` entsprechend angepasst.

Für ordering-Übung werden zwei Partitionen benötigt!

Setup mit 3 Broker und Topic-Erzeugung mit Setup für acks-Übung

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

Setup aus der Intro-Übung übernommen

Setup "entkernt": Implementierungen entfernt

Upgrade der Images von Confluent 6.2.0 auf 7.0.2

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

Fälschlich hartkodiertes Topic gegen Variable getauscht

Code reorganisiert, um Änderungen vergleichbarer zu machen

Upgrade für Spring Boot 2.6.0 -> 2.6.5

* Kafka: 3.0.1
* Spring Kafka: 2.8.4

First Contact: Simple Producer & Consumer