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

refactor: Renamed the test to `InMemoryWithFilesStorageIT`

feat: Refined `ChatBackendApplicationTest`

- Switched to a full server-startup (no MockMvc).
- Added some requests, that check the availability of the expected data.

refactor: refined the endpoint-uri's

feat: Introduced config switches to choose the used implementations

- Switched the existing `@Configuration`-classes into an auto-configuration.
- Added a `@ConditionalOnProperty`, that loades the default-configuration.
- Added an Auto-Configuration for the `MongoDbStorageStrategy`, which is
  inactive by default and can be switched on by the property
  `chat.backend.storage` to `mongodb`.

feat: configuration for service & storage lives in the according packages

test: Activated the maven-failsafe-plugin

fix: Added constraints for valid usernames

- This fix is necessary, because not all usernames can be stored in
  the newly introduced `MongoDbStorageStrategy`.

feat: Implemented and tested `MongoDbStorageStrategy`

- Beware: The version 4.0.0 of Spring Data MongoDB that is included in
  Spring Boot 3.0.x does not work with version 4.8.1 of the MongoDB drivers
  that are included. Therefore, the version of the drivers was downgraded
  to 4.7.2 - See:
  https://docs.spring.io/spring-data/mongodb/docs/current/reference/html/#compatibility.matrix
- Also tried an upgrade of Spring Boot from 3.0.0 to 3.0.1, but without
  luck.
- Beware: Spring Boot 3.x does not include an autoconfigured embedded
  version of MongoDB for testing. It removed the autoconfiguration for
  `de.flapdoodle.embed:de.flapdoodle.embed.mongo` !

refactor: Refined (simplified) `StorageStrategy`

refactor: Moved `FilesStorageStrategy` in its own package -- Rename