Konfiguration in application.yml verschlankt

`@KafkaListener`-Version des `spring-consumer`

Konsumption der Nachricht in eine separate Methode verlagert

* Dies ist eine Vorbereitung für die Umstellung auf `@KafkaListener`
* Durch die Umstellung wird der Code vor/nach der Umstellung besser
  vergleichbar.
* Denn mit `@KafkaListener` wird direkt eine Methode annotiert, die dann
  von Spring die deserialisierte Nachricht injiziert bekommt.

Version des Simple-Consumer, mit Auto-Konfiguration durch Spring Kafka

Spring-Boot Version des Simple-Consumer

Das Setup lässt sich mit `docker-compose up setup` starten

.editorconfig ergänzt - siehe: ttps://editorconfig.org/

* Einziger gangbarer Weg, um IntelliJ beizubiegen, Leerzeichen für die
  Einrückung zu verwenden!
* ...aber auch für einige andere Dinge ganz praktisch...

Das konfigurierte Topic wird auch verwendet

unsubscribe() im Fehlerfall ergänzt

Name/Beschreibung in POM an andere Versionen angepasst

Compose-Setup und README.sh an überarbeitete Übung angepasst

README.sh an geändertes Compose-Setup angepasst

Umstellung auf 1 Controller und 3 Broker

Setup auf KRAFT umgestellt

* Der Zookeeper wird dann nicht mehr benötigt.
* Broker-Images auf `bitnami/kafka:3.3.1` umgestellt, da die Confluent-
  Images den KRAFT-Modus noch nicht unterstützen.

Verwendete Syntax in docker-compose vereinheitlicht

Fix: Übung Consumer-Groups mit simple-consumer

Initiale Lese-Position auf die älteste bekannte Nachricht gesetzt

Implementierung an Folien angepasst: Beendigung durch `+Consumer.wakeup()+`

Vorführung der Übung verwendet den `simple-producer`

Ausführung von README.sh resilienter

Compose-Setup an das aus den Producer-Übungen angepasst

* Es wird jetzt der Rest-Producer verwendet.
* Um die Nachrichten zu erzeugen, werden die Rest-Clients verwendet.
* Ziel: Dies ist näher an dem Setup aus den Wordcount-Übungen.
* Versucht das Timing in dem README-Skript unabhängiger von Timing-Fragen
  zu machen - scheitert aber daran, dass das Skript nicht gezielt darauf
  warten kann, dass das neu angelegte Topic zur Verfügung steht.

Asciidoc-Tags entfernt

Für eine Übersichtliche Übergabe sollte CooperativeStickyAssignor aktiv sein

* Per Default ist immer noch der RangeAssignor vorgegeben, so dass die
  Partitionen bei jedem Rebalance komplett neu zugeordnet werden.
* Um bei der Betrachtung der Effekte von Sauberem Stop vs. Kill vs. Freeze
  den Überblick behalten zu können, wurde der CooperativeStickyAssignor
  aktiviert.

Anpassungen des Projekts/Setups aus 'simple-producer' übernommen

Implementierung des Consumers aus 'first-contact' vereinfacht

* Code für ordentliches Herunterfahren so weit wie möglich vereinfacht.
* Dabei den Code möglichst eng an die Producer-Implementierung angelehnt.

Angleichungen zwischen Producer/Consumer

Fehlerchen in Logmeldung korrigiert

Möglichst einfach gehaltener technisch vollständiger Producer

* Unterschiede zu dem Producer aus `first-contact`:
** Der Producer erzeugt endlos alle ca. 500ms eine Nachricht.
** Der Producer beendet sich ordentlich, wenn STRG-C gedrückt wird.
** Der Producer wird auch als Docker-Image gebaut
* Das Compose-Setup an das Setup aus den vorhergehenden Übungen
  angegelichen.

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

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