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.

refactor: Introduced `ConsumerTaskExecutor` -- Copied class

refactor: `KafkaChatHomeServiceTest` reuses regular startup-logic

refactor: `KafkaServicesApplicationRunner` without autowireing

refactor: Renamed `ChatRoomService` into `ChatMessageService` -- ALIGNE

refactor: Renamed `ChatRoomService` into `ChatMessageService` -- MOVE

refactor: Removed unused methods

refactor: Renamed `persistence` into `implementation` - Aligned code

refactor: Renamed `persistence` into `implementation` - Moved classes

refactor: `storage` is not a sub-package of `persistence` - Aligned code

refactor: `storage` is not a sub-package of `persistence` - Moved classes

refactor: `ChatHome` is a service - Aligned code

refactor: `ChatHome` is a service - Moved classes

refactor: Moved exceptions into package `exceptions` - Aligned Code

refactor: Moved exceptions into package `exceptions` - Moved classes

refactor: Moved `ShardingStrategy` into package `persistence` -- ALIGNE

refactor: Moved `ShardingStrategy` into package `persistence` -- MOVE

refactor: Splitted `ChatRoomInfo` and `ChatRoomData` - Aligned Code

refactor: Splitted `ChatRoomInfo` and `ChatRoomData` - Moved classes

test: Refactored test-code

refactor: Simplified implementation - Removed interface `ChatRoomFactory`

* Moved method `ChatRoomFactory.createChatRoom(UUID, String)` to `ChatHome`.
* Allowed `null`-values for `ChatRoom.shard`.
* Moved logic from `InMemoryChatHomeService` into `SimpleChatHome` respective
  `ShardedChatHome` and removed obsolete class.
* Adapted the configuration of the tests to the model changes:

feat: Upgraded Spring Boot 3.0.1 -> 3.1.3

refactor: `ShardNotOwnedException` should be send over `Mono.send()`

test: Added tests for a chat-home _with_ shards

test: Added tests for a chat-home (without shards)

LoadInProgressException - ALIGN

LoadInProgressException - MOVE

test: Simplified `ChatBackendControllerTest`

feat: `UnknownChatroomException` records shard and owned shards

fix: GREEN - Correct handling of unknown chat-rooms in the Kafka-version

test: RED - Added a test for a put to a non-existent chat-room

feat: first runnable implementation, that is based on Kafka

refactor: Removed Interface `ChatHomeService`

refactor: Moved implementation details out of `domain` -- Aligned code

refactor: Moved implementation details out of `domain` -- Moved classes

fix: GREEN - Fixed NPE in `ShardedChatHome.getChatRoom()` for foreign shard

* `ShardedChatHome.getChatRoom(UUID)` know checks, if a `ChatHome` exists
  for the selected shard.
* If no `ChatHome` exists, a `ShardNotOwnedException` is thrown.
* The `ChatBackendControllerAdvice` translates the exception to an error
  of type 404 - NOT FOUND, to fullfill the defined expectations.

test: RED - Proofed existence of an NPE in `ShardedChatHome.getChatRoom()`

- Refined `AbstractConfigurationIT` to show, that an NPE can occure in
  `ShardedChatHome.getChatRoom()`.
- Defined the expected behaviour, if the NPE is handled correctly in the
  refined integration-test.

feat: Implemented new Default-`StorageStrategy` `none'

* If `none` is selected as storage strategy, an empty implementation of
  `Storage-Strategy` instanciated.
* The owned shardes are derived from the according configuration property.
* Before, they were derived from the stored data.

refactor: `ChatRoomFactory` returns real `ChatRoom`s

- `ChatHomeService` only deals with real `ChatRoom`s.
- Hence, there is no need for `ChatRoomFactory`, to return the simplified
  interface `ChatRoomInfo`.
- This is, because the implementation specific logic is implemented in the
  `ChatHomeService`, not `ChatHome` itself: the actual implementation is
  hidden behind that service (and behind the service `ChatRoomService` in
  the domain-class `ChatRoom`).

refactor: Refined the creation of new `ChatRoom`s

- Dropped `ChatHomeService.putChatRoom(ChatRoom)`.
- `ChatRoomFactory.create(UUID, String)` returns `ChatRoomInfo`.

refactor: DRY for the configuration of the `AbstractStorageStrategyIT`

refactor: Refined the configuration of `AbstractStorageStrategyIT'

refactor: `ChatRoomService.persistMessage(..)` returns a `Mono<Message>`

refactor: Simplified the handling of `MessageMutationException`

test: Added a test that assers disjunct chatrooms

chore: Added a Docker-Build

feat: Reintroduced `ChatRoom.shard`, becaus it is needed as a routing-hint

- Technically, the attribute is not needed.
- But, to implement the gua/sha-pattern, it is needed as routing-hing.
- Hence, it is reintroduced here and also added to the `ChatRoomTo` to
  be send to the client.

fix: Fixed a NPE in `ShardedChatHome.getChatRooms()`

- When collecting the `ChatRoom`s for all shards, unused shards with a
  `null` value were not skipped.
- Also added log-messages of level `INFO` for the creation of `ChatRoom`,
  `SimpleChatHome` and `ShardedChatHome`.

fix: Removed unnecessary generic in `ChatHomeService`

chore: Switched the default-configuration to sharding `none`

refactor: A `ChatRoom` does not have to remember its shard any more

- The shard of a `ChatRoom` can be derived from its ID, if the configured
  `ShardingStrategy` is known.
- Because the `ShardingStrategy` is known everywhere, where the shard of a
  `ChatRoom` is needed, it always can be derived dynamically.

refactor: Pulled business-logic into class `ShardedChatHome`

- Pulled the logic that selects the appropriate shard from the class
  `ChatBackendController` into the newly introduced class
  `ShardedChatHome`.
- Simplified the configuration
  - `InMemoryServicesConfiguration` creates a `ChatHome` of type
    `SimpleChatHome`, if the `sharding-strategy` `none` is choosen.
  - In that case, the values for `num-shards` and `owned-shards` are
    ignored and set to `1` and `0`.
  - If the `sharding-strategy` is set to `kafkalike`, a `ChatHome` of
    type `ShardedChatHome` is instanciated and the configuration
    respects the configured sharding.
- Simplified the configuration of `ChatBackendControllerTest` accordingly.

refactor: Made `SimpleChatHome` an implementation of `ChatHome`

refactor: Removed `ChatHomeFactory`

- `ChatHomeFactory` was only used during initialization.
- By moving the instanciation of `chatHomes` into the implementation-
  specific configuration, the necessity of the factory vanished.

feat: Introduced a kafka-like `ShardingStrategy` for `inmemory`

- Introduced the `ShardingStrategy`, that picks a shard for a given
  `ChatRoom`-ID.
  - Implemented a `KafkaLikeShardingStrategy`, that reuses the hashing
    algorithm, that is implementd in `Utils.murmur2()` in the
    `org.apache.kafka:kafka-clients` library.
  - The attribute `shard` of the `ChatHome` has to be restored according
    to the configured `ShardingStrategy` when loading the state - it must
    not be safed with the stored data, because it might change due to
    configuration-changes.
- The `ChatBackendController` was not configured correctly, because it
  had consumed the single `ChatHome` from the old configuration as the
  only entry in its `ChatHome[]`-array.
  - Refined the application-properties: Introduced an inner subclass
    `InMemoryServicesProperties` of `ChatBackendProperties`, that
    encapsulates the properties, that only concern the implementation
    `inmemory`.
  - Added the configuration-parameters `numShards` and `ownedShards`,
    that are needed by `inmemory`, to handle the sharding correctly.
- Introduced `ChatHomeFactory`, because the `ChatHome`s are instanciated
  by `ChatBackendConfiguration`, which is not aware of the configured
  implementation.
- Adjusted the test-cases to the changes.
- Added `InMemoryWithFilesAndShardingConfigurationIT`, that asserts,
  that the application works as expected, if sharding is activated.

test: Streamlined the config-IT, so that they use the same expectations

- Both tests now use the same data and expect the same results.
- Moved the actual tests and assertions to `AbstractConfigurationIT`.
- Also streamlined `AbstractStorageStrategyIT`, so that it produces
  the exact same data, that the configuration-tests are expecting.
  This is not a necessary change to get the refined coniguration-tests
  running. It just makes it easier, to produce the needed test-data for
  future refinements.
- Also streamlined the naming of the directory, where
  `InMemoryWithFilesStorageIT` stores its data.

refactor: Tried to simplify & clearify the naming of the integration-tests

refactor: DRY für shard-selection

feat: Prepared the application for sharding

- The `ChatBackendController` stores the `ChatHome`s in an array.
- Reintroduced a `ChatRoomFactory`

test: Added integration-test `InMemoryWithMongoDbStorageIT`

fix: Supressed mongo-autoconfiguration if `FilesStorageStrategy` is active