Fix & Refactor: Restore-Behandlung wurde _allen_ aktiven Partitionen zuteil

* Durch das vorausgehende Refactoring wurde deutlich, dass die Behandlung,
  die den _neu_ hinzugefügten Partitionen zugedacht war, allen in
  `assignedPartitions` vermerkten Partitionen wiederfahren ist.
* Dies ist für den aktuellen Entwicklungsstand ggf. egal, da der wegen dem
  Co-Partitioning (noch!) benötigte `RangeAssignor` eh _zuerst alle_
  Partitionen entzieht, bevor er _dann alle_ neu zuteilt.
* Da der Code aber auch mit dem neuen Consumer-Rebalance Protokoll
  funktionieren muss, wurde das Refactoring hier fortgeführt und so
  vollendet, dass nun _alle_ Aktionenen _nur noch_ von den Callbacks
  `onPartitionsAssigned()` und `onPartitionsRevoked()` ausgeht.

Refactor: Handling von pause/resume vollständig in State-Change-Methoden

DRY für state-change zu RESTORING

Refactor: Neue, klarere ``switch``-Syntax

Refactor: DRY für state-change zu UNASSIGNED

Refactor: DRY für state-change zu ASSIGNED

Refactor: Logik für Counter in Klasse `CounterState` extrahiert

Der Zustand wird aus dem ``state``-Topic wiederhergestellt

Fix: `poll()` liefert nicht immer Nachrichten zu _allen_ Partitionen

* Ein Aufruf von `poll()` liefert _nicht unbedingt_ Nachrichten zu _jeder_
  Partition, die der Instanz gerade zugeteilt ist.
* Daher konnte es auftreten, dass eine Phase nie beendet wurde, wenn
  `poll()` nur Nachrichten zu einer Untermenge der aktiven Partitionen
  geliefert hat.

Fix: Nachrichten wurden ggf. doppelt verarbeitet

* Wenn man in einer Schliefe die Nachrichten pro Partition separat
  verarbeitet...
* ...dann sollte man in jedem Schleifendurchlauf auch nur die Nachrichten
  der gerade zu verarbeitenden Partition abrufen!

Fehler im Logging der aktiven Phase korrigiert und Meldungen verbessert

Fix: Der Rebalance-Listener wurde nie registriertgit diff

Log-Meldungen für das Senden des Zählerstands ergänzt

Log-Meldungen zum Fortschritt beim Versenden des Zähler-Status ergänzt

Fix: Fehler müssen wie bestätigte Nachrichten behandelt werden

* Ohne explizite Fehlerbehandlung müssen auch die nicht bestätigten
  Nachrichten als `acked` gezählt werden.
* Ansonsten würde die Verarbeitung in einem ``poll()``-Durchlauf mit Fehler
  hängen bleiben, da niemals alles "gesehenen" Nachrichten auch als
  "bestätigt" gezählt würden.
* Dabei: Producer-Code an den aus `producer/spring-producer` angeglichen.

Der Value-Typ in dem Topic `state` ist jetzt auch vom Typ `String`

* Dadurch wird die Kontrolle der Ergebnisse einfacher, da alle Nachrichten
  auch einfach mit `kafkacat` gelesen werden können.

Der Zustand des Zählers wird in einem compacted Topic abgelegt

* Der Consumer zählt, welche Nachrichten gesendet und welche bestätigt
  wurden.
* Über einen `Phaser` wird sichergestellt, dass alle Nachrichten von den
  zuständigen Brokern bestätigt wurden, bevor der nächste ``poll()``-Aufruf
  erfolgt.

GET-Endpoint zum Abfragen der Schlüssel-Zählungen ergänzt

* Zugriff auf die `counterMap` in `ExampleConsumer` synchronisiert.
* `CounterStateController` kopiert die Map, um mögliche konkurierende
  Zugriffe während des Erzeugens der Ausgabe zu vermeiden.

Die Counter werden mit dem ``String``-Key indiziert

* Vorbereitung auf eine Poison-Pill Übung ist hier noch out-of-scope...

Der Consumer zählt, wie oft die Schlüssel auftreten

Das Docker-Setup verwendet den `spring-producer`

* Die Konfiguration wurde außerdem so überarbeitet, dass der Producer
  mehr Nachrichten verschickt (ca. 10 Nachrichten pro Sekunde) und diese
  in Batches à ca. 6 Nachrichten verpackt.

Ungefangene Exceptions im `ExampleConsumer` lösen das Beenden der App aus

Fix: `close()` muss noch vom `ExampleConsumer` aufgerufen werden

* Der Aufruf von `close()` löst die Abmeldung der Instanz bei dem
  GroupCoordinator aus.
* Dieser Vorgang sollte noch unter der Kontrolle des Anwendungscodes
  erfolgen!
* Wenn die Methode erst von Spring aufgerufen wird, werden dann ggf. noch
  Seiteneffekte ausgelöst, die dann noch im Kontext der Instanz laufen,
  obwohl diese eigentlich schon beendet wurde!

Consumerspezifische Properties werden in eigener nested Class verwaltet

* Dadurch wird der Code übersichtlicher, wenn spätere Implementierungen
  _sowohl_ als Consumer, _als auch_ als Producer agieren!

`ExampleConsumer` in eine Spring-Boot App umgebaut (ohne Spring Kafka)

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

`metadata.maxage.ms` auf 5 Sekunden heruntergesetzt

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`

`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