feat: Shard-ownership is published asynchronously

test: Implemented IT for `HaproxyDataPlaneApiShardingPublischerStrategy`

* Enabled the HAProxy Data Plane API in the configuration, that is used
  for the tests that start an instance of HAProxy inside a container.

feat: GREEN - Implemented `HaproxyDataPlaneApiShardingPublisherStrategy`

test: RED - Expectations for `HaproxyDataPlaneApiShardingPublischerStrategy`

refactor: Renamed `ShardingStrategy` for HAProxy Runtime API -- ALIGN

refactor: Renamed `ShardingStrategy` for HAProxy Runtime API -- MOVE

test: HandoverIT-POC - FIX: writers/listeners must send the `X-shard`-header

* `@Disabled` the Handover-IT temporarily, because the fix disclosed,
  that some fixes and refactorings are needed, before the IT can work
  again.
* That is, because the implemented `HaproxyShardingPublisherStrategy`
  does _not_ properly updates the sharding-map.

refactor: Fixed a warning for events concerning `@EqualsAndHashCode`

test: HandoverIT-POC - the sharding-map is logged during backend-starts

test: HandoverIT-POC - `TestWriter` logs an error, if sending fails

test: HandoverIT-POC - logging the progress during the start of a backend

feat: Implemented problem-details for `ChannelNotReadyException`

feat: Implemented problem-details for `ChatRoomInactiveException`

test: HandoverIT-POC - FIX: `TestWriter` must use `Flux#concatMap()`

* `Flux#flatMap()` executes in parallel. Hence, the enqueued messages
  are _not_ send in the order, that they were enqueued.
* Therefore, the `TestWriter` was refactored to use `Flux#concatMap()`,
  which executes serially.

fix: `ChatRoomData` must only be activated after restoring completes

fix: GREEN - Implemented activation/deactivation of `ChatRoomData`

* Introduced `volatile ChatRoomData#active`, which initially is `false`.
* `ChatRoomData#listen()` throws `ChatRoomInactiveException` if inactive.
* `ChatRoomData#addMessage(..)` throws `ChatRoomInactiveException` if
  inactive.
* `SimpleChatHomeService` explicitly activates restored and newly created
  instances of `ChatRoomData`.
* `DataChannel` explicitly activates instances of `ChatRoomData`, if
  they are restored during partition-assignment or, if a new chat-room
  is created.
* `DataChannel` explicitly _deactivates_ instances of `ChatRoomData`,
  if the associated partition is revoked.
* Also: Introduced `ChatMessageService#getChatRoomId()`.

test: RED - Formulated expectations for active vs. inactive `ChatRoomData`

* Introduced the methods `ChatRoomData+activate()` and
  `ChatRoomData#deactivate()`.
* Added tests to `ChatRoomDataTest`, that assert the expectations.
* Added tests to `AbstractConfigurationIT`, that assert the expectations.

fix: GREEN - `ChatRoomData` obeys to the added expectations.

* Switched `ChatRoomData` from a multicast- to a replay-sink.
* Before, listening was implemented with a multicast-sink, that enabled
  back-pressure.
* Now, it was refactored to use a replay-sink, that enables a (configurable)
  limitted replay.

test: RED - Added test for multiple parallel Listeners to `ChatRoomDataTest`

* The test formulates the expectation, that late listeners should see all
  messages (for a reasonable long period before their subscriptions)
* The test _fails_, because the implementation only buffers messages for
  backpressure -- _not for replay!_

test: Fixed `AbstractConfigurationIT#testPutMessageInNewChatRoom()`

* In the case, that the request that adds a messag failed, the longly
  process of creating a new chat-room, until it has the correct shard,
  was unnecessarily repeated.
* Different workarounds have to be applied at the same time for the two
  implementations:
** Because `ShardedChatHomeService` only throws a `ShardNotOwnedException`,
   if the shard, that is picked by the strategy is not owned, the result
   is retried until the requests succeeds by chance.
** The `KafkaChatHomeService` always creates the chat-room in the
   partition, that is derived from the randomly picked id.
   Hence, the loop, that is only left, if the randomly picked partition
   matches the partition `2`, that the test-instance owns.
** Since `SimpleChatHomeService` does not know the concept of sharding
   at all, the loop is also left, if no shard is set (shard is ``null``).

test: Refined `AbstractConfigurationIT#testPutMessageInNewChatRoom()`

* Removed unnecessary asserts: the expected result of the creation of a
  chat-room is no concern of this test.
* Simplified the assertion of the shard.

test: Fixed `AbstractConfigurationIT#testPutMessageInNewChatRoom()`

* The first request in the awaited assertion must create a chat-room,
  that is owned by the instance.
* Hence, _it has to_ assert, that the shard of the created chat-room is
  `2` - the only shard, the test-instance owns, or _empty_, if the instance
  under test does not implement sharding.

test: Added tests for listening to `ChatRoomDataTest`

test: Refactored `ChatRoomDataTest` - made mocking more clear

* When mocking the results of calls to `ChatMessageService`, the returned
  message does naturally _not_ reflect the parameters of the call.
* Hence, a arbitrary message is used whenever the test only asserts,
  that a value, that was returened by `ChatMessageService` is handed
  through as expected by `ChatRoomData`.

test: Removed unnecessary Mockito-recordings in `ChatRoomDataTest`

test: `ChatRoomDataTest` verifies that persistence is triggered as expected

test: Refactored `ChatRoomDataTest` - DRY for message attributes

test: HandoverIT-POC - Refactored `TestListener`

test: HandoverIT-POC - Added logging for complete/error to listener

test: HandoverIT-POC - Waiting for the assertion when all messages are sent

test: HandoverIT-POC - Refactored the startup of backend-containers

* The backend-containers are explicitly started during the test.
* When a backend is started, it is waited for, that the started backend
  reportes its status as `UP`, _and_, that alle writers are again able to
  send messages, afterwards.

refactor: Simplified the configuration for the kafka-services

* Removed class `ChannelTaskRunner` and `KafkaServicesApplicationRunner`.
* Instead, the method `ChannelTaskExecutor.excuteChannelTask()` is executed
  as `@Bean.initMethod` by Spring.
* Adapted the test-cases accordingly:
** Joinig the channel-tasks is not necessary any more, because that is
   done by the imported production-config
** `KafkaConfigurationIT` has to call `executeChannelTasks()`
   explicitly
** Therefore, it has to overrule the default-config for the bean
   `dataChannelTaskExecutor` in order to drop the configuration of the
   `initMethod`.
** Otherwise, the test would (might) not restore the data from the topic,
   because the messages, that are send into the test-cluster, might arrive
   only after the initial loading of the data is done.

refactor: Removed config-dependencies from `ChannelTaskExecutor`

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

WIP:test: HandoverIT-POC - Excuting the Flu...

WIP:test: HandoverIT-POC - Excuting Flux...

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

WIP:test: HandoverIT-POC - Clients are stopped after some time

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.

chore: The GitHub-Action for the Maven-Build is triggerd for all branches

chore: Renamed action to "Maven-Build"

chore: Activated IT in GitHUB-Maven-Build

chore: Create maven.yml

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`.