Version des Consumers, die bei Last an Dauer des Poll-Loop scheitert

* Der Consumer legt bei Nachrichten, deren Nachrichten-Inhalt (als Zahl
  betrachtet) modulo 7 glatt aufgeht, eine zufällige Schaffens-Pause von
  0 - 2000 ms ein.
* Außerdem wurde `max.poll.interval.ms` auf 5 s heruntergesetzt und
  `max.poll.records` auf 30 Nachrichten.
* Die Werte wurden über fleißiges ausprobieren so abgestimmt, dass dieser
  Consumer regelmäßig daran scheitert, alle Nachrichten innerhalb der
  vorgegebenen 5000 ms zu verarbeiten, so dass man in den Logs sehr gut
  den asynchron durch den Backrgound-Thread erzeugten Leave-Group Request
  erkennen kann, der bereits erfolgt, _bevor_ der Consumer alle Nachrichten
  verarbeitet hat, erneut `poll()` aufruft und _erst dann_ erfährt, dass
  ihm die Partitionen inzwischen entzogen wurden.
* Um dies noch besser erkennen zu können, wurden außerdem Log-Meldungen vor
  und nach der Schaffens-Pause und - insbesondere - nach der Verarbeitung
  aller erhaltenen Nachrichten eingefügt.
* *BEACHTE:* Der Consumer scheitert nur, wenn sich zuvor ein gewisser
  Rückstau gebildet hat. Solange er in "Echtzeit" eine Nachricht pro Sekunde
  erhält, hat er natürlich keine Probleme.
* Um den Fehler auszulösen, muss der (ansonsten nicht angepasste) Producer
  also mind. 30 Sekunden gelaufen sein, ohne dass ein anderer Consumer die
  Nachrichten konsumiert hat.

`ConsumerRebalanceListener` implementiert, der die Änderungen logged

Setup für Spickzettel-Übung um Service `spickzettel` erweitert

Setup für Consumer-Group-Übung um `ute` und `peter` erweitert

Fehler beim Beenden korrigiert: `running = false` zu früh!

Fehlermeldung & Abbruch anstatt hartkodierter Standard-Konfig

Spezial-Einstellungen entfernt, die die TN nicht haben

Partition & Offset stehen eindeutig in der Log-Meldung

Handling der Records wie in abgeleiteten Versionen in eigener Methode

`metadata.maxage.ms` auf 5 Sekunden heruntergesetzt

`simple-producer` in `simple-consumer` verwandelt -- ALIGN

`simple-producer` in `simple-consumer` verwandelt -- COPY

Migration Spring-Boot 4.0.2 -> 4.0.6

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

refactor: Überflüssige Docker-Hilfsdateien entfernen

.dockerignore und .maven-dockerinclude gehören zum alten
Dockerfile/fabric8-basierten Build-Workflow und werden von
Jib bzw. bootBuildImage nicht benötigt.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

refactor: Dockerfile und manuelle Jar-Packaging-Konfiguration entfernen

Seit der Umstellung auf Jib ist das Dockerfile nicht mehr nötig.
maven-dependency-plugin und maven-jar-plugin-Konfiguration (Classpath-
Manifest) waren nur für den manuellen Docker-Build-Weg erforderlich.
Jib übernimmt das Packaging vollständig; mainClass ist nun explizit
in der Jib-Konfiguration gesetzt.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

refactor: Docker-Build von fabric8/bmuschko auf Jib umstellen

Maven nutzte das io.fabric8:docker-maven-plugin mit einem handgepflegten
Dockerfile. Gradle kopierte das JAR umständlich in ein target/-Verzeichnis,
damit dasselbe Dockerfile funktioniert (COPY target/*.jar).

Beide Build-Systeme nutzen jetzt Jib (com.google.cloud.tools:jib-maven-plugin
bzw. com.google.cloud.tools.jib), das direkt aus den compilierten Klassen
und Abhängigkeiten ein OCI-Image erzeugt:

  Maven:  mvn package  (jib:dockerBuild ist an package-Phase gebunden)
  Gradle: ./gradlew jibDockerBuild

Für den Registry-Push:
  Maven:  mvn jib:build
  Gradle: ./gradlew jib

Vorteile:
- Kein Dockerfile mehr nötig (kein Kopier-Hack in Gradle)
- Beide Build-Systeme verwenden dieselbe Methode
- Optimiertes Layering (Abhängigkeiten in separaten Layern)
- Kein laufender Docker-Daemon für den Build nötig

Außerdem: gradle-git-properties Plugin hinzugefügt, analog zum
git-commit-id-plugin in Maven.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

fix: Lombok in Maven korrekt als optional deklarieren

Lombok war mit <scope>compile</scope> deklariert, was dazu führt, dass
es als transitive Abhängigkeit weitergegeben wird. Da Lombok ein reines
Compile-Zeit-Tool (Annotation Processor) ist, muss es als <optional>true</optional>
markiert werden. Der Spring-Boot-Maven-Plugin schließt optionale
Abhängigkeiten automatisch aus dem fat-JAR aus.

Das Gradle-Setup ist in diesem Punkt bereits korrekt (compileOnly +
annotationProcessor).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Client-ID in Shutdown-Meldungen ergänzt

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`

Migration Apache-Kafka 4.1.1 -> 4.1.2

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

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