Verbesserungen und Fachlogik-Test aus 'sumup-adder' gemerged

test: Überprüfung der Fachlogik ergänzt

* Überall, wo die Fachlogik geprüft wird, wird jetzt sichergestellt,
  dass die berechneten Ergebnisse den Erwartungen entsprechen.
* Überprüft, werden nur die zu dem Zeitpunkt tatsächlich vollständig
  berechneten Ergebnisse. Dadurch wird durch die Überprüfung kein Fehler
  ausgelöst, wenn wegen einem simulierten Fehler noch nicht alle durch
  die erzeugten Nachrichten angeforderten Berechnungen erfolgt sind.

refactor: Inline-Klasse in `ApplicationTests` ist jetzt statische Klasse

* Diese Refaktorisierung ist nötig, damit dem `RecordGenerator`
  der Zugriff auf die Ergebnisse der Fachlogik in `AdderResults`
  ermöglicht werden kann.
* Grund: Wenn der `RecordGenerator` bereits im Konstruktor erzeugt wird,
  kann er nicht auf die `this`-Referenz von `ApplicationTests` zugreifen.

Die Ergebnisse werden gespeichert und sind via REST abrufbar

GRÜN: Implementierung der Erwartungen inkl. Anpassungen an der Anwendung

* Neue Erwartungen an `AdderBusinessLogic` implementiert.
* Die Implementierung hat sich über die nicht von den Unit-Tests
  abgedeckte Methode auch auf andere Teile der Anwendung ausgewirkt.
* `AdderBusinessLogic.getState()` liefert jetzt in der Map die neue
  Klasse `AdderResult` und benötigt diese auch als Konstruktor-Argument.
* Über die Integration-Tests ist sichergestellt, dass die Datenhaltung
  trotz der Umstellung von `Long` auf `AdderResult` funktioniert.

ROT: Zur Summe soll die Zahl ausgegeben werden - Logik + Test angepasst

* `AdderBusinessLogic` gibt jetzt ein `AdderResult` zurück, das die Summe
  zusammen mit der zugehörigen Zahl ausgibt.
* Anwendung (insbesondere die Signatur von `AdderBusinessLogic`!)
  entsprechend angepasst.
* Erwartungen an `AdderBusinessLogic` entsprechend überarbeitet.

GRÜN: Neue Erwartungen umgesetzt

ROT: Signatur für `AdderBusinessLogic` und neue Erwartungen formuliert

* Anwendung so überarbeitet, dass sie weniger motzig ist, dafür aber
  einfach Rechenfehler produziert - weil diese bei Experimenten leichter
  nachvollziehbar sind.
* Dafür eine neue Signatur für `AdderBusinessLogic` entwickelt, die
  Implementierung aber noch nicht angepasst.
* Die neuen Erwartungen an `AdderBusinessLogic` formuliert.

fix: Fehlerhafte Erwartung korrigiert

GRÜN: (ungewollt!) - Unabhängigkeit der Tests wieder hergestellt

* Die Mongo-DB wird jetzt zwischen den Tests gewaltsam mit `drop()`
  geleert.
* Dadurch wirkt sich der Test, bei dem die Verarbeitung durch einen
  Logik-Fehler unterbrochen wird, nicht mehr auf den/die anderen Tests aus.

ROT: Rückbau auf automatische Commits - Testfälle laufen nicht mehr

* Rückbau von sumup-adder auf automatische Commits, so wie in dem
  Branch stored-state - D.h., nur noch der Zustand wird in der Mongo-DB
  gespeichert.
* Durch den Umbau schlägt `ApplicationTests` fehl, obwohl sich eigentlich
  nichts an der Logik geändert hat.
* Dies ist so "gewollt": Es zeigt, dass bei automatischen Commits im
  Fehlerfall der gespeicherte Zustand und der Stand der verarbeiteten
  Nachrichten auseinander laufen.
* _Unschön:_ Die Tets sind nicht mehr unabhängig voneinander.
** Eigentlich war erwartet, dass der Test, der den Fehler erzeugt
   beim 2. Anlauf fehlschlägt, weil durch die doppelt gelesenen
   Nachrichten weitere Fehler auftreten - diese unterscheiden sich aus
   der Sicht des Test-Codes aber gar nicht von den vorherigen Fehlern.
** Als _ungewollter_ Seiteneffekt bleibt aber der Zustand in der Mongo-DB
   zurück, der zwischen den Tests nicht zurückgesetzt wird.
** Dadurch scheitert dann der folgende Test, der eigentlich durchlaufen
   sollte.
** Genauer: Ob und/oder Welche Tests fehlschlagen, hängt von der
   Ausführungs-Reihenfolge ab!
* *Idee:* `AdderBusinessLogic` weniger motzig implementieren, indem
  anstatt von getrennten START- und STOP-Nachrichten nur noch eine
  CALC-Nachricht verwendet wird, die die Summe der zuvor aufgelaufenen
  Zahlen ausgibt.
** Passt besser zu der ursprünglichen Idee, dass an den falchen Summen
   leicht gezeigt werden kann, dass Nachrichten doppelt verarbeitet wurden
** Die Idee mit den ungültigen Zuständen führt davon ab! Bei doppelt
   verarbeiteten Nachrichten ist dann nur noch der invalide Zustand
   sichtbar, zu den mit der Gauß-Summenformel leicht als falsch zu
   entlarvenden Summen kommt es dann gar nicht mehr...

Benennung vereinheitlicht und projektunabhängig gemacht

fix: In `onPartitionsAssigned()` wurde der Kafka-Offset ausgegeben

GRÜN: Korrektur des über die verschärften Tests aufgedeckten Fehlers

ROT: Verbesserungen aus 'deserialization' in 'sumup-adder' gemerged

* Dabei: Die Verbesserungen aus 'deserialization' genutzt, um in
  `ApplicationTests` einen angepassten `RecordGenerator` zu
  implementieren.
* Da der Service derzeit mit `String` für Schlüssel und Nachricht
  arbeitet, kann keine Poison-Pill erzeugt werden (null-Nachrichten
  führen nicht zu einer `DeserializationException` und alles andere
  lässt sich in einen - fachlich ggf. sinnfreien - String konvertieren).
* Der Test für Logik-Fehler schlägt fehl, weil er einen Fehler in der
  Implementierung aufdeckt!
* Alle bisherigen Versionen von `EndlessConsumer`, die ihre Offsets in
  der Mongo-DB mit speichern führen bei einer `DeserializationException`
  einen Offset-Commit durch, wenn ihnen durch das darauf folgende
  `unsubscribe()` die Partitionen entzogen werden.
* D.h., bisher wurden in dieser Situation Nachrichten verloren!

Methode zu prüfen der Fachlogik in `RecordGenerator` ergänzt und angebunden

Signatur und Handling des `RecordGenerator` vereinfacht/überarbeitet

* Der `RecordGenerator` darf jetzt selbst bestimmen, wie viele Nachrichten
  er erzeugt und wo wieviele Poison-Pills oder Logik-Fehler erzeugt
  werden, wenn der Test dies anfordert.
* Dafür git der `RecordGenerator` jetzt die Anzahl der tatsächlich
  erzeugten Nachrichten zurück, damit die Tests richtig reagieren können.

Anzahl der erzeugten Test-Nachrichten wird vom `RecordGenerator` bestimmt

GRÜN: Erwartungen implementiert

ROT: Übersehene Erwartung an SumBusinesLogic.endSum(String) ergänzt

refactor: Benennung der Fachlogik-Tests vereinheitlicht

Implementierung des Adders für SumUp

* `AdderRecordHandler` und `AdderRebalanceListener` implementiert, die
  die separat entwickelte Fachlogik anbinden.
* `StatisticsDocument` in `StateDocument` umbenannt und angepasst.
* Als Zustand wird zunächst nur der interne Zustand der Fachlogik
  ausgegeben.
* Später sollen statdessen die für die Benutzer durchgeführten
  Berechnungen ausgegeben werden, damit diese validiert werden können.

Namen der Test-Klassen korrigiert

`GenericApplicationTest` überspring Tests, wenn Fehler nicht verfügbar

* Über eine Annotation wird für Tests, die einen bestimmten Fehler-Typ
  benötigen bei dem `RecordGenerator` nachgefragt, ob der Fehler-Typ
  erzeugt werden kann.
* Wenn der Fehler-Typ nicht zur Verfügung steht, wird der Test
  übersprungen.

Tests aus gemerged springified-consumer--serialization -> deserialization

* Es wurde nur der hinzugefügte Test übernommen.
* Der hinzugefügte Test wurde an das von Spring-Kafka abweichende
  Verhalten bei einem Logik-Fehler angepasst: Kafka führt nicht automatisch
  Seeks oder einene Commit durch. Da `EndlessConsumer` bei einem
  Logik-Fehler explizit ein `unsubscribe()` durchführt, wird kein
  Offset-Commit durchgefürt, so dass die alten Offset-Positionen gültig
  bleiben.
* Der Test wurde entsprechend umbenannt.
* `RecordGenerator` wurde um einen weiteren Integer-Set erweitert, über
  den die Indizes der zu erzeugenden Logik-Fehler gesetzt werden können.
* Der hinzugefügte Test wurde auf die überarbeitete Methode zur Erzeugung
  der Test-Nachrichten umgestellt.
* `ApplicationTest` wurde so ergänzt, dass der für den hinzugefügten Test
  benötigte Logik-Fehler erzeugt wird.

Typisierung in `GenericApplicationTest` nur noch, wo wirklich nötig

* Es wird nur noch dort mit Typisierung gearbeitet, wo dies unumgänglich
  ist, weil die typisierte Implementierung angesprochen wird.
* Das Versenden der Test-Nachrichten erfolgt als `Bytes` für Schlüssel
  und Nachricht.
* Dadurch muss der `RecordGenerator` nicht mehr typisiert werden.
* Dafür muss die typisierte Implementierung des Testfalls dann Schlüssel
  und Nachricht mit einem passenden Serializer in eine `Bytes`-Payload
  umwandeln.

`ApplicationTest` auf basis der typisierbaren Basis neu implementiert

Typisierbare Basis-Klasse `GenericApplicationTests` eingeführt

GRÜN: Erwartungen implementiert

ROT: Erwartungen an SumBusinessLogic.addToSum(String, Integer)

GRÜN: Erwartungen implementiert

ROT: Erwartungen an SumBusinessLogic.endSum(String)

GRÜN: Erwartungen implementiert

ROT: Erwartungen an SumBusinessLogic.getSum(String)

GRÜN: Erwartungen implementiert

ROT: Erwartungen an SumBusinessLogic.startSum(String)

Demonstration für das Wordcount-Beispiel angepasst

Demonstration in README.sh gepimped

Verbesserte/Erweiterte Tests aus 'stored-offsets' nach 'wordcount' gemerged

Der Integration-Test prüft auch, ob der HealthIndicator 'UP' zurückgibt

Integration-Test hinzugefügt, um die Lauffähigkeit der App sicherzustellen

Fixes für Setup/README.sh aus 'deserialization' in 'stored-offsets' gemerged

Compose-Setup und README.sh für dieses Beispiel repariert

* Zuvor war in dem Setup noch ein Producer konfiguriert, der Nachrichten
  vom Typ `String` geschrieben hat, so dass der Consumer _sofort_ das
  zeitliche gesegnet hat.
* Im README-Skript wurde nicht darauf gewartet, dass der Consumer
  gemeldet hat, dass er ordentlich gestartet ist, bevor er nach der
  vermeintlichen Konsumption der Poison-Pill wieder neu gestartet wurde.

Verbesserungen aus 'deserialization' nach 'stored-offsets' gemerged

Refaktorisierungen aus 'wordcount' nach 'stored-offsets' zurück portiert

refactor: Alle Kafka-Belange in den `WordcountRebalanceListener` verschoben

* Dafür neues Interface `PollIntervalAwareRebalanceListener` eingeführt.
* `WordcountRebalanceListener` implementiert das neue Interface und
  kümmert sich um alle Kafka-Belange.
* `WordcountRecordHandler` kümmert sich nur noch um die Fachlogik.

refactor: Handling der Partitionen in WordcountRebalanceListener

refactor: RebalanceListener als eigenständige Klasse

refactor: Implementierung an Branch `stored-offsets` angepasst

Wordcount-Implementierung mit Kafka-Boardmitteln und MongoDB als Storage

* Zählt die Wörter pro Benutzer.
* Simple Implementierung mit Maps.
* Verwendet die bereits für das Speichern der Nachrichten-Zählung und
  der Offsets verwendete MonogoDB-Anbindung zum speichern.
* Typisierung zurückgenommn: Immer String für Key/Value
* Verwendet aus Bequemlichkeit den Seen-Endpoint von der Zählung.

Umstellung des Nachrichten-Datentyps auf Long zurückgenommen

* Im Branch 'deserialization' wurde der Datentyp der Nachricht von `String`
  auf `Long` umgestellt, um eine `DeserializationException` vorzuführen, die
  innerhalb des Kafka-Codes geworfen wird.
* Diese Änderung wurde schon dort nicht in dem `README.sh`-Skript
  reflektiert.
* Hier stört sie jetzt die Experimente mit dem `EndlessProducer`, der
  Nachrichten vom Typ `String` erzeugt, so dass der Consumer kein einzige
  Nachricht annehmen kann.
* Daher wird der Nachrichten-Datentyp hier wieder auf `String` zurück
  umgestellt.
* Dafür musste auch der Testfall angepasst und der Test entfernt werden, der
  die Exception kontrolliert.

Auf den `CooperativeStickyAssignor` umgestellt

Das Speichern der Daten und Offsets erfolgt nicht mehr nach jedem `poll()`

* Statdessen kann eine `Duration` konfiguriert werden.
* Ähnlich wie in der Client-Library von Kafka, wird ein Zeitstempel für
  den letzten Commit gespeichert und die Daten werden immer dann
  gespeichert, wenn dieser weiter als das eingestellte
  `consumer.commit-interval` in der Vergangenheit liegt.

Wenn kein gespeicherter Offset vorliegt, auto.offset.reset von Kafka nutzen

* Es wird jetzt nur noch dann ein expliziter Seek durchgeführt, wenn eine
  gespeicherte Offset-Position gefunden wurde.
* Andernfalls wird der von Kafka initialisierte Ausgansgs-Offset verwendet.
* Welchen Offset Kafka vorgibt, hängt von `auto.offset.rest` ab!

Fehler im Shutdown-Code korrigiert: Shutdown von `EndlessConsumer` zu spät

mongo-express sollte erst nach der MongoDB gestartet werden

Ausgabe der verarbeiteten Nachrichten im Revoke-Callback entfernt

* Es musste allein für diese Ausgabe eine Map mit den zuletzt eingelesenen
  Offset-Positionen gepflegt werden.
* Das ist zu viel Overhead, für die Randmeldung im Log.

Fehler in Logging-Ausgabe korrigiert

* Der über den Merge hinzugefügt Test hat einen Fehler aufgedeckt.
* In onPartitionsRevoked() wurde bei der Berechnung der verarbeiteten
  Nachrichten für die Log-Ausgabe ein Nullzeiger dereferenziert.
* Ursache dafür war, dass die Map `offsets` in der Version, die die Offsets
  speichert gar nicht mehr gepflegt wurde.

Merge der Refaktorisierung des EndlessConsumer (Branch 'stored-state')

* Die `commtSync()`-Aufrufe machen beim Speichern der Offsets außerhalb
  von Kafka keinen Sinn mehr.
* Der Testfall musste an die extern gespeicherten Offsets angepasst
  werden: Die gesehenen Offsets müssen aus der MongoDB gelesen werden,
  anstatt über einen separaten Consumer aus Kafka.
* Der mit dem Merge hinzugefügte Test schlägt fehl, da er einen Fehler
  aufdeckt (NPE bei einer Log-Ausgabe zur Offset-Verarbeitung).

Test prüft ungültige und unbekannte Nachrichten

Verbesserungen des Testfalls gemerged (Branch 'deserialization')

Verhalten des Testfalls kontrollierbarer gemacht

* Die Awaitility-Aufrufe pollen den zu prüfenden Zustand wenn nicht anders
  angegeben so häufig, wie es die CPU zulässt - also ohne Verzögerung
  zwischen den Überprüfungen.
* Das kann den Rechner temporär so überlasten, dass der erwartete Zustand
  in der abgewarteten Zeit gar nicht eintritt!
* Z.B. aufgetreten, wenn wie hier das Commit-Interval auf 1 Sekunde
  gesetzt ist, das Polling von Awaitility aber noch ungebremst durchgeführt
  wird.
* Um diese Quelle für falsche Fehler auszuschließen, wurde jetzt
  durchgängig ein Poll-Intervall von 1 Sekunde für Awaitility gesetzt.

Testfall überarbeitet

* Abhängigkeit der Testergebnisse von Ausführreihenfolge beseitigt.
* Die Abhängigkeit bestand, da die Offset-Positionen als Zustand die
  Testausführung überdauert haben.
* Daher konnte kein weiterer Test mehr ausgeführt werden, nachdem einmal
  eine Poison-Pill in das Topic geschrieben wurde, über die der
  implementierte Consumer stolpert.
* Um das zu umgehen, werden die Offset-Positionen jetzt nach jedem Test
  auf das Ende der Partitionen verschoben. D.h., wenn in dem Test eine
  Poision-Pill geschrieben wird, über die der implementierte Consumer
  nicht hinweglesen kann, werden die Offests vor der Ausführung des
  nächsten Tests über diese Poision-Pill hinweg gesetzt.
* Dadurch ist wurde ein Fehler / eine Schwäche in der Testlogik aufgedeckt:
  In dem Test für das erfolgreiche Schreiben wurde nur deswegen ein Commit
  ausgeführt, weil zuvor noch kein Commit durchgeführt wurde, so dass der
  Default-Wert für das Commit-Interval immer überschritten war.
* Um das zu umgehen, wurde eine Konfigurations-Option für das Setzen des
  Parameters `auto.commit.interval` eingeführt, so dass im Test
  sichergestellt werden kann, dass auf jeden Fall in dem beobachteten
  Zeitraum ein automatischer Commit ausgelöst wird.
* Außerdem: Weniger verwirrende Ausgabe des Offset-Fortschritts.

Deserialisierung von Nachrichten unterschiedlichen Typs

Refaktorisierungen des Testfalls gemerged (Branch 'deserialization')

Verwendung eines weniger verwirrenden Key in Tests (fachlich irrelevant)

Erzeugung von ProducerRecord in Test refaktorisiert

Merge der Refaktorisierung des EndlessConsumer (Branch 'deserialization')

* Um die Implementierung besser testen zu können, wurde die Anwendung
  in dem Branch 'deserialization' refaktorisiert.
* Diese Refaktorisierung werden hier zusammen mit den eingeführten
  Tests gemerged.
* Der so verfügbar gemachte Test wurde so angepasst, dass er das Speichern
  des Zustands in einer MongoDB berücksichtigt.

Merge der überarbeiteten Compose-Konfiguration ('deserialization')

Merge der überarbeiteten Compose-Konfiguration ('rebalance-listener')

Merge der überarbeiteten Compose-Konfiguration ('stored-state')

README.sh startet MongoDB und Mongo-Express

Merge der überarbeiteten Compose-Konfiguration ('rebalance-listener')

* Dabei auch die letzten Verbesserungen aus 'rebalance-listener' übernommen.

Merge der überarbeiteten Compose-Konfiguration ('counting-consumer')

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

* Die letzten Änderungen an 'endless-stream-consumer' sind länger nicht
  mehr gemerged worden.

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 (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

Merge branch 'deserialization' into springified-consumer--serialization

Fehler in Shutdown-Logik für den `ExecutorService` korrigiert

Merge branch 'rebalance-listener' into deserialization

Merge branch 'endless-stream-consumer' into rebalance-listener

HealthIndicator implementiert: Implementierung selbst vergessen :/

Refactor: `EndlessConsumer` ist selbst ein `ConsumerRebalanceListener`

* Vorbereitung für die Übernahme der Funktionalität in der springifizierten
  Version.

Springify: Nachrichten-Typ wird über den Type-Info-Header bestimmt

Springify: Der Payload ist eine als JSON gerenderte Klasse

* Als Nachricht wird eine Instanz der Klasse `ClientMessage` erwartet
* Die Instanz wird mit Hilfe des `JsonDeserializer` von Spring Kafka
  deserialisiert.

Tests: Refaktorisiert - Durcheinander bei Assertions aufgeräumt

* Zuvor wurden die Assertions von JUnit Jupiter und AssertJ durcheinander
  gewürfelt verwendet.
* Jetzt werden stringent nur noch die Assertions von AssertJ verwendet.

Tests: Refaktorisiert - Serialisierung des Payloads konfigurierbar gemacht

Tests: Tests prüfen den Status des Consumers

Tests: Refaktorisiert - Nachrichten werden für alle Tests aufgezeichnet

Tests: Fehlerfall-Test prüft, dass nicht alle Nachrichten gelesen wurden

Tests: Assert-Beschreibungen korrigiert/ergänzt

Tests: Geprüft, dass der Fehler nach einem Neustart neu vorliegt

Tests: Umbau für einen Commit im Fehlerfall und Anpassung des Tests

Tests: Refaktorisiert - Methoden-Reihenfolge aufgeräumt und kommentiert

Tests: Der Test wartet, bis die Offsets regulär committed wurden

* Zuvor wurde der Offset-Commit erzwungen, indem der EndlessConsumer
  über den Aufruf von `stop()` beendet wurde.
* Jetzt wird die Überprüfung der Erwartungen über awaitility aufgeschoben,
  bis die Erwartungen beobachtet werden können - oder eine Zeitschranke
  gerissen wird.

Tests: Der EndlessConsumer wird jetzt doch asynchron ausgeführt

* Der Test-Code wird verständlicher, wenn der Consumer asynchron läuft
* Für die Überprüfung der Erwartungen wird dann awaitility benötigt
** Da der Consumer in einem separaten Thread läuft, muss auf diesen
   gezielt gewartet werden
** Dafür wird es deutlicher/verständlicher, auf welche der auch aus dem
   regulären Betrieb des EndlessConsumer bekannten Zustandsänderungen
   der Test wartet
* Da die Offsets für die Controlle (ggf.) abgefragt werden, während der
  EndlessConsumer noch läuft, wird ein separater KafkaConsumer benötigt,
  um die Offsets abzurufen.
  BEACHTE: Um die Änderungen in dem Offsets-Topic zu greifen zu bekommen,
  muss dieser KafkaConsumer für jede Abfrage ein `assign()` durchführen,
  damit er gezwungen ist, die Offsets neu vom Broker zu erfragen.

Tests: Refaktorisiert - DRY für Test auf Offset-Fortschritt

Tests: Überprüft, ob überhaupt ein Offset-Fortschritt vorliegt

Tests: Offsets werden unter TopicPartition abgelegt