refactor: Simplified shutdown - channel-tasks were joined multiple times

* `KafkaServicesApplicationRunner` does not have to join the channel-tasks.
* The channel-tasks are already joined by `ChannelTaskExecutor.join()`
  automatically, because the method is annotated with `@PreDestroy`.
* Simplified the test-configuration accordingly.

fix: The shutdown of the application was blocked

* The auto-configured bean `applicationTaskExecutor` must not block, while
  it is shutting down, because otherwise, it infinitly waits for the
  completion, of the channel-tasks, which are stopped in a _later_ phase
  of the "smart" lifecycle.
* The bean is destroyed first, becaus it is is associated with the lowest
  lifecyle-phase (``Integer.MAX_VALUE``), which apparently cannot be
  overruled by `@DependsOn` (although suggested by the spring-
  documentation)
* Joining the channel-tasks was blocking infinitly, because the tasks were
  waiting for the kafka-consumers to be closed, what only happens _after_
  the joining completes.

fix: Detection of the `READY`-state for `InfoChannel` was flawed

feat: Implemented and configured health-indicator for the ``Channel``s

refactor: Refined channel-states, introduced `ChannelState` -- ALIGN

* Renamed attributes and method-names according to the class-renames.
* Introduced interface `Channel` and `enum ChannelState`.
* `Data` - and `InfoChannel` maintain a `ChannelState`, instead just a
  plain boolean, that only reflects the loading-state.
* The `ChannelTaskRunner` waits, until both channels entered the State
  `ChannelState.SHUTTING_DOWN`.

refactor: Refined channel-states, introduced `ChannelState` -- MOVE

* Renamed and moved `LoadInProgressException`
** Moved exception into implementation-specific package
** Renamed exception to `ChannelNotReadyException`
* Renamed `ConsumerTaskExecutor` into `ChannelTaskExecutor`
* Renamed `ConsumerTaskRunner` into `ChannelTaskRunner`

test: HandoverIT-POC - Added assertions for the sent/received messages

test: HandoverIT-POC - fix for the blocking wait for `TestListener`

* Droped the waiting for `TestListener` alltogehter.
* The waiting can be droped, because waiting for the `TestWriter`-instances
  ensures, that all messages are send (and therefore very likely received)

test: HandoverIT-POC - working fix: using `delayElements()`

* Switched from `Flux.flatMap(Mono.delay()..)` to
  `Flux.from(..).delayElements()`FIX:delay_vs_delayElements.
* This delays eache element of the `Flux` by the same amount.
* The requests are made, when the according element of the flux is
  executed - not when the `Flux` is created, as before.

test: HandoverIT-POC - not working fix: using `delay()`

* Switched from `Mono.from(..).delayElement()` to `Mono.delay().then()`.
* This does _not_ solve the problem, that all delays are calculated and
  scheduled, when the `Flux` is created.

test: HandoverIT-POC - FIX: `take(n)`, does end the work after n elements

* `take(n)` does end the execution.
* `limitRate(n)` limits the rate of requested elements.

test: HandoverIT-POC - Executing the Flux/Mono asynchrounusly

test: HandoverIT-POC - Listener/Writer remember received/sent messages

test: HandoverIT-POC - Refactored listening into class `TestListener`

test: HandoverIT-POC - Refactored `TestWriter` to use a `Flux`

test: HandoverIT-POC - Each `TestWriter` writes only to one chat-room

test: HandoverIT-POC - Refactored / Cleaned up

test: HandoverIT-POC - Renamed `TestClient` to `TestWriter` -- ALIGN

test: HandoverIT-POC - Renamed `TestClient` to `TestWriter` -- MOVE

test: HandoverIT-POC - Fixed illegal client-naming (one character only)

test: HandoverIT-POC - Fixed logging of failed client-requests

fix: Fixed `ConcurrentModificationException` when accessing a chat-room

* If a new chat-room was created, `InfoChannel` only reacted with the
  creation of the according `ChatRoomInfo`-instance.
* The creation of the accompanying `ChatRoomData`-instance through
  `DataChannel` was posponed until the new chat-room was accessed the
  first time.
* That way, `InfoChannel` did not need to know `DataChannel`, so that a
  cyclic dependency could be avoided.
* As a downside, this approach was open to a race-condition: if several
  accesses to the newly created chat-room happend in parallel, a
  `ConcurrentModificationException` was thrown, since the instance of
  `ChatRoomData` was created multiple times in parallel.
* To circumvent the locking, that would be necesarry to evade this race
  condition, the approach was refactored, so that `InfoChannel` now
  explicitly triggers the creation of the `ChatRoomData`-instance.
* To do so without introducing a cyclic dependency, the class
  `ChannelMediator` was introduced, so that `InfoChannel` and `DataChannel`
  need not to know each other.

refactor: Introduced `ChannelMediator`

* `InfoChannel` and `DataChannel` must not know each other directly.
* This is necessary, to prevent a cyclic dependency, that would otherwise
  be introduced, if `InfoChannel` also has to communicate with
  `DataChannel`.

test: HandoverIT-POC - clients are stopped after some time

test: HandoverIT-POC - running multiple clients in parallel

test: HandoverIT-POC - added a delay to the sending-loop

test: HandoverIT-POC - remodeled sending into a for-loop

test: HandoverIT-POC - messages are written to 23 chat-rooms instead of 1

test: HandoverIT-POC - splitted up code into smaller classes -- ALIGN

test: HandoverIT-POC - splitted up code into smaller classes -- MOVE

test: HandoverIT-POC - Moved general container-defs into base-class

test: HandoverIT-POC - setup without static containers

test: HandoverIT-POC - first working setup for the planned test

* First working POC of the setup for the planned test.
* This version blocks endlessly, because the SSE-flux never completes.

fix: Errors during shard-publishing should not kill the instance

* `HaproxyShardingPublisherStrategy` has to transform any exception into
  a `Mono.error()`.
* `DataChannel.onPartitionsAssigned(..)` has to log and swallow errors
  during the propagation of the shard-ownership.

fix: Sensible value for sink-buffer

feat: Made polling-interval for Kafka configurable

fix: The number of chards is the number of partitions of the `data_channel`

fix: Disabled mongodb-autoconfig, if mongodb is not used

feat: Switched to `spring-boot-starter-data-mongodb-reactive`

feat: Added logging for io.projectreactor to `MongoDbStorageStrategy`

refactor: DRY for logging-category from io.projectreactor

feat: Added counting of restored instances

test: `StorageStrategy`-IT are restoring instead of recreating

fix: GREEN - Fixed the restore-mechanism

* The code of a reactive flow _must not_ call blocking functions.
* In order to solve this, the restore-process is triggered explicitly
  after the creation of the classes.

refactor: RED - Refined success/error-handling for restore-operations

* This innocent little change discloses a severe missconception in the
  implementation of the storage strategies.
* The call to `Mono.block()`, though not really changing the behaviour
  during the restore-process, triggers a sanity-check from
  io.projectractor.

test: Simplified the integration-tests for `StorageStrategy`

test: Simplified `InMemoryWithMongoDbStorageIT`

* Switched to `@ServiceConnection` instead of hand-coded initializer.

test: Added IT for `ChatRoomRepository` and `MessageRepository`

test: Simplified & Unified the Kafka-tests

test: Simplified `ChatHomeServiceTest`

* Removed the unnecessary explicit instantiation of the `ObjectMapper`.

test: Simplified & unified test-setup for ``ChatHomeServiceTest``s

* Using existing configuration-classes instead of hand-coded configuartion.
* Aligned the `KafkaChatHomeServiceTest` with the `in-memory`-tests.

refactor: Cleaned up code

feat: Introduced counting of stored instances in `StorageStrategy`

feat: Introduced config-parameters for the `io.projectreactor`-logging

refactor: Set logging-level for io.projectreactor to `DEBUG`

refactor: Refined stream-definition in `StorageStrategy#write`

* Changed the stream-definition to a more natural order.
* As a result, the stored `ChatRoomInfo`-instances do not have to be
  handed clumsily to the following stream.

refactor: Refined return-type of `StorageStrategy#write`

refactor: One stream -> using `flatMap` instead of an inner `subscribe`

refactor: Moved succes/error-logging to outer stream-definitions

refactor: Simplified `StorageStrategy`

* Reconfigurable success/error-logging was introduced for
  `NoStorageStorageStrategy`.
* But as it turns out, this strategy can simply apply its logging in the
  overwritten method, that disables the whole storing-logic.
* Hence, the interface was greatly simplified again, by removing this
  ununsed mechanism.

refactor: Moved extracted the `subscribe()`-call from `StorageStrategy`

* The subscription does no more happen inside the implementations of the
  interface `StorageStrategy`.
* Instead, the methods, that are defined in `StorageStrategy` return the
  created `Flux`.
* The call to `subscribe()` happens in the code, that uses this methods.
* This faciliates feature refinements concerning the asynchronous handling
  of success- and error-cases and so forth.

refactor: Extracted subscription into a separate method-call

* This is in preparation to a planed refinement.
* The refinment will move the `subscribe()`-call out of the implementation
  of the `StorageStrategy`.

test: Added missing JSR-310 module to not Spring-Boot-based tests

feat: Added log message for disabled storage

fix: Without `@DirtiesContext` the app is not teared down correctly

* `StorageStrategy` depends on Spring to call the method
  `ChatBackendApplication#onExit()`, that is annotated with `@PreDestroy`.
* If this method is not called, the strategy is not applied, which leads
  to errors in the integration-tests.
* This happens, if all tests are run through Maven, because Spring
  recycles the application-context and only tears down the context after
  all tests have run.
* The addition of `@DirtiesContext` on those tests forces Spring to tear
  down the application completely after each so annotated test.
* Hence, the method is called as expected, which fixes the described
  errors.

test: Introduced integration-tests for `NoStorageStorageStrategy`
--
ALIGN

test: Introduced integration-tests for `NoStorageStorageStrategy`
--
COPY

refactor: Extracted annonymous class into `NoStorageStorageStrategy`
--
ALIGN

refactor: Extracted annonymous class into `NoStorageStorageStrategy`
--
COPY

refactor: Added success- and failure-callbacks for `ChatHomeService`

refactor: Added success- and failure-callbacks to `StorageStrategy`

refactor: `KafkaServicesApplicationRunner` aufgeräumt

fix: Config-ITs do not fail, if run multiple times

fix: Removed manual version-management for testcontainers.org

feat: Upgraded Spring Boot 3.1.3 -> 3.2.2

fix: `getChatRoomInfo()` thrwos `LoadInProgressException` when loading

- The method `InfoChannel.getChatRoomInfo(UUID)` has to check, if loading
  is in process.
- Otherwise, an existing chat-room might erronously not be found, if it is
  requested, while `InfoChannel` is loading, because it is not yet loaded.

refactor: compute `loadInProgress` on offset-change

refactor: separated message- and record- (aka offset-) handling

refactor: Renamed method in `InfoChannel` according to conventions

refactor: Made only locally used method in `KafkaChatHomeService` private

feat: The position of the last seen messages is stored on a revoke

fix: The actual position has to be requested from the consumer

* If the last seen offset and the current offset differ, although the
  partition did not contain any messages between this offsets, the loading
  process got stuck, because the position never advanced.
* Therefore, the actual position, that is compared against the read
  end-offset, has to be requested from the consumer.

refactor: Added logging of loaded messages

refactor: Refined success/error-handling when publishing shard-ownership

feat: Implemented `HaproxyShardingPublisherStrategy`

* Implemented a first simple `ShardingPublisherStrategy`, that uses the
 https://www.haproxy.com/documentation/haproxy-runtime-api/[HAProxy Runntime API]
 to publish changed ownerships.
* Added configuration-properties `kafka.haproxyRuntimeApi` and
  `kafka.haproxyMap` to configure the strategy.

feat: Introduced interface `ShardingPublisherStrategy`

* The interface is used by `DataChannel` to publish the changed ownership
  each time, a new partition is assigned to the consumer-group.
* Added a dummy-implementation in `KafkaServicesConfiguration`.

feat: Introduced a configurable instance-id

fix: `ConsumerTaskRunner` waits until the data-loading is finished

feat: Introduced events that are send, if a shard is assigned/revoked

* In order to redirect requests to the appropriate instances, each
  instance must know the mapping from  shard-IDs to instance-URIs.
** For the static `in-memory`-implementation `ShardedChatHomeService`,
   this is a static mapping, that can be configured and read on start-up.
** For the dynamic `KafkaChatHomeService`, this mapping has to be
   propageted to all instances each time the partition-assignment of the
   consumer-group changes.
* Changes for `ShardedChatHomeService`
** Introduced `ChatBackendProperties.shardOwners` (of type `URI[]`).
** Each instance reads the static mapping from shard-ID to instance-URI
   on start-up.
* Changes for `KafkaChatHomeService`
** Introduced `KafkaServicesProperties.instanceUri` (of type `URI`).
** Each instance reads its URI on start-up.
** `DataChannel` sends an event for each assigned/removed partition,
   when the partition-assignment of the consumer-group changes.
** These events propagete the changed mapping from partition-ID to
   instance-URI.
** `InfoChannel` receives these events and updates the dynamic mapping
   from partition-ID (aka:shard-ID) to instance-URI.
* The shards, that are owned by an instance, can be queried via `/shards`.

fix: `metadata` is never `null`

refactor: DRY for computation of new `ChatRoomData` instances

fix: GREEN - `DataChannel` creates entries for existent chat-rooms

test: RED - Putting a message in a newly created chat-room

refactor: Splitted test in `AbstractConfigurationIT` into smaler pieces

refactor: Moved common test-code into helper-class `KafkaTestUtils` - ALIGN

refactor: Moved common test-code into helper-class `KafkaTestUtils` - COPY

refactor: Extracted interface `WorkAssignor` into separate file

refactor: Separated channels for data and info -- Refactored/aligned code

* Split `ChatRoomChannel` into `InfoChannel` and `DataChannel`
** `DataChannel` manages only data for chat-messages
** `InfoChannel` manages all info-data (at the moment only
   `EventChatRoomCreated`)
* Aligned test-setup for kafka-related tests

refactor: Separated channels for data and info -- Moved/copied classes

* Split `ChatRoomChannel` into `InfoChannel` and `DataChannel`
** `DataChannel` manages only data for chat-messages
** `InfoChannel` manages all info-data (at the moment only
   `EventChatRoomCreated`)
* Aligned test-setup for kafka-related tests

refactor: Introduced `ConsumerTaskExecutor` -- Aligned code

* Moved startup-logic in a separate class (`ConsumerTaskExecutor`), so
  that it is reusable more easily in test scenarios.
* `KafkaServicesApplicationRunner` is instanciated via `@Component`, so
  that it is _not_ instanciated automatically, if the configuration is
  triggered explicitly via `KafkaServicesConfiguration` in test scenarios.