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

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

refactor: `FileStorageStrategy` is not bound to `InMemoryChatRoomService`

refactor: Moved classes in package `persistence` in sub-packages -- Rename

refactor: Moved classes in package `persistence` in sub-packages -- Move

refactor: Introduced `AbstractStorageStrategyIT` as base for more tests

- Moved the test-logic, that does not depend on implementation-details
  into an abstract base-class `AbstractStorageStrategyID`.
- `LocalJsonFilesStorageStrategyIT` extends this class and only instances
  for that specific implementation and the accompanying setup.

fix: `ChatBackendApplicationTest` cannot corrupt the real data anymore

- The test used the default storage-direcory.
- Because the app is sometimes aborted during the shutdown, this sometimes
  lead to corrupted data in the default storage-directory.
- The test now uses a predefined set of data underneath the build-directory.
- Also changed the name of the according property to `storage-directory`.

fix: Refined `ChatBackendControllerTest` and fixed a bug in `ChatRoom`

- Only `ChatHomeService` and `ChatRoomService` are mocked.
- This makes the test more robust, because there are less sources for
  false positives or wron negatives because of wrongly mocked behaviour.
- Aforementioned is proofed by an unnoticed bug, that was discoverd by
  the freshly refined test.

feat: Moved persistence-logic from `ChatHome` into `ChatHomeService`

- Aligned configuration and tests accordingly.
- Also fixed some camel-case typos.

refactor: Moved business-logic from `ChatRoomService` into `ChatRoom`

- Some essential business-logic -- the identification of mutated messages --
  was buried in `InMemoryChatRoomService`.
- This business-logic was moved into `ChatRoom`, becaus otherwise, it
  would have been necessary, to reproduce this logic in each and every
  new implementation of `ChatRoomService`, which would have been exhausting
  and errorprone.
- This allowed also cleaner code in `InMemoryChatRoomService`, that
  can focus on the persistence-logic.
- The implementation of `MessageMutationException` and the look of the
  accompanying problem-details hat to be refined accordingly.

fix: Asserted, that `ChatHome` acts, as expected, if asked for a `ChatRoom`

refactor: Streamlined the API of the services

- `ChatRoomService` and `ChatHomeService` both return only reactive types.
- The decission stems from the wish, to become reactive all the way from
  the client to the technical implementation of the backend-services.
- This faciliates the mapping of the results in `ChatBackendController`.
- The refactoring already simplified lots of code, where a `Flux` has
  to derived from the `Stream`, yielding a good feeling about the plan,
  that is pursued with this refactoring.
- The refactoring also lead to the decision that `UnknownChatroomException`
  realy is a business-logic-exception (that according refactoring was
  already performed in the previous commits, to ceap this commit clean).

refactor: `UnknownChatroomException` is a business-exception - Relocate

refactor: `UnknownChatroomException` is a business-exception - Move

fix: Fixed generated problem-details for mutated messages

feat: Implemented problem-details for `UnknownChatroomException`

- Implemented an `@ExceptionHandler` for `UnknownChatroomException`.
- Implemented `ChatBackendControllerTest`
  - Asserted, that the problem-details are generated as expected
  - Pinned down problems, that yield a refactoring and have to
    be resolved afterwards.

refactor: Added assertj-reactor for more readability

test: `LocalJsonFilesStorageStrategyIT` asserts, that the state is restored

fix: Implemented a test for `MessageTo` and fixed deserialization

test: Implemented a first IT for `LocalJsonFilesStorageStrategy`

- This first version of the test does not realy test the storing.
- It is only a proof-of-concept for the setup.

refactor: The `ChatRoom` determines the timestamp of a `Message`

refactore: Renamed `ChatroomService` to `ChatRoomService` -- Rename

refactore: Renamed `ChatroomService` to `ChatRoomService` -- Move

refactore: Renamed `ChatroomTo` to `ChatRoomTo` -- Rename

refactore: Renamed `Chatroom` to `ChatRoom` -- Rename

refactore: Renamed `ChatroomFactory` to `ChatHomeService` -- Rename

refactore: Renamed `ChatroomFactory` to `ChatHomeService` -- Move

refactore: Renamed `PersistenceStrategy` to `ChatroomService` -- Rename

refactore: Renamed `PersistenceStrategy` to `ChatroomService` -- Move

refactor: Only `LocalJsonFileStorageStrategy` restores `Chatroom`s

feat: Added an endpoint that list all messages of a chatroom

refactor: `LocalJsonFilesStorageStrategy` is now realy reactive

fix: The sink is recreated, if it gets canceled

- The sink is automatically cancelled, if the last consumer leaves.
- Turning auto-cancel of, is not an option, because this buffers new
  messages, until the buffer overflows, after which new messages are
  droped. Hence, if a new subscriber arrives, it would see some old
  messages and then, after a gap, current messages.
- Because of that, the sink is now automatically recreated, if the
  last subscriber leaves and triggers the automatically cancelation
  of the sink.
- The sink can be recreated without conflicts, because all methods,
  that may access the sink are synchronized.

feat: Server sends real Server-Sent-Events

feat: The size buffer for listeners to a chatroom is configurable

feat: Allowed the frontend as origin for CORS

feat: Added a POST-mapping to force the storing of the data

refactor: Fixed return-types of the controller

- Renamed and moved `ChatroomInfo` to `ChatroomTo`
- Switched return-types from `Chatroom` to `ChatroomTo`

fix: `Chatroom`s must not share an instance of `PersistanceStrategy`

feat: The chats are stored as local json-files

feat: `ChatHome` returns an `Optional` for `getChatroom(UUID)`

feat: Introduced `ChatHome` that gives multiple `Chatroom`s a home

refactor: Moved configuration in a separate class and made it more explicit

refactor: Introduced `ChatroomFactory`

- `ChatBackendController` only has to know of the `ChatroomFactory`.
- `ChatBackendController` does not have to know the `PersistenceStrategy`.

refactor: Moved persistence-logic into a pluggable strategy

refactor: A `Message` now explicitly has a `MessageKey`

refactor: Streamlined API of `Chatroom` - all return-types are reactive

refactor: Refined field-names of `Message` and `MessageTo`

- Choosed longer and more descriptive field-names for the domain-class
  `Message`.
- Choosed short names for the TO-class `MessageTO`, which is serialized as
  JSON.

feat: `Chatroom.getMessages()` is fully paginated (takes first and last)

refactor: Refined packaging (renamed packages and classes)

refactor: Refined packaging (moved classes to new folders and files)

refactor: Renamed artifact to chat-backend

refactor: Reworked implementation of the problem-details [RFC-7807]

feat: Added problem-details [RFC-7807] for a message mutation error

feat: An `IllegalArgumentException` is thrown, if different messages are added for the same `MessageKey`

feat: Added logging for the `listen`-endpoint

fix: fixed the return-type of the `listen`-endpoint

feat: Implemented an endpoint to get the details of a chatroom

feat: implemented a listen-method for the chat-service based on a Flux

- Switched the return-type of `Chatroom.addMessage()` to `Mono<Message>`.
- Added an inner method, that "persists" the message and also returns
  `Mono<Message>`.
- `addMessage()` calls `persistMessage()`, peeks into the subscription and
  emits the `Message` to an internal `Sink.multy()` of the `Chatroom`.
- `Chatroom.listen()` creates a `Flux` from the internal Sink, so that
  multiple subscribers can listen on the sink and all retrieve the current
  messages in parallel.

feat: implemented a simplified chatroom-service

chore: Switched configuration from *.properties to YAML

refactor: Simplified the name of the application-class

chore: Fixed indentation of the `pom.xml`

chore: Removed the Maven-Wrapper

feat: Generated empty Spring Boot 3.0.0 App