query: 2.0.1 - (GREEN) Adjusted implementation to corrected expectations

query: 2.0.1 - (RED) Corrected expectations for JSON in input-messages

query: 2.0.0 - (GREEN) Explicitly specifed the missing serde-config

query: 2.0.0 - (RED) The keys of the top10-topic are deserialized as JSON

* The seemingly straightforward change leds to a very strange and
  inconsisten error-situation.
* Only the integration-test fails, while the topology-test works as
  originally expected.
* The cause of the error is a missing serde-config for the key of the
  ``rankings``-``KStream``, which defies easy explanation.
* The best explanation is, that the ``map()``-operation - despite
  possibly changing the type of the key and/or value - does not by itself
  define a parameter for specifing a corresponding serialization-config.
* The reason for this is, that the operation does not define the complete
  operation by itself.
* In order to take effect, it has to be combined with a second operation,
  that actually creates the outgoing topic.
* Without that second DSL-operation, `map()` simply would yield no action.
* And that is, why the serialization has to be defined on that second
  operation and cannot be defined on `map()` itself.
* But the really strange thing about the error is, that it _only_ shows up
  in `QueryApplicationIT`.
* It does not show in `QueryStreamProcessorTopologyTest` _and_ it does
  _not_ show up, if the application is compiled and started in the
  docker-setup.
* One possible explanation for this wired behaviour might be a bug or
  misconception in the interpretation of the beforehand build topology,
  that leads to a non-deterministic behaviour.
* Another possible explanation might be subtle differences in the internal
  caching behaviour -- but that seems unlikely, because tests, that are
  based on the `TopologyTestDriver` do not cache and are very (on the oposit)
  very handy if one wants to reveal bugs concerning the serialization and
  and running the application with the caching settings from the IT does
  not show the error.

query: 2.0.0 - (GREEN) Adjusted the implementation to the new expectations

* Messages from the incomming topic, that is written by the `users` service
  can be serialized, although no type-information is conveyed via the
  headers.

query: 2.0.0 - (RED) Corrected expectations for the ``users``-input-topic

* The messages that are written by the `users` service doese _not_ contain
  any type-information.
* This commits corrects the corresponding expectations in the test-cases.
* *RED:* The tests fail, because the implementation was not yet fixed!

query: 2.0.0 - `QueryApplicationIT` uses two ``KafkaTemplate``s

* Switched the setup of the `QueryApplicationIT` to use two different
  instances  of `KafkaTemplate` for the two input-topics.
* This is a preparation for the introduction of the typed JSON-keys.

query: 2.0.0 - Refined the Lombok-Annotations for the model-classes

query: 2.0.0 - Configured caching & commit-interval in integration-test

* Introduced configuration-parameters for caching and the commit-interval.
* Explicitly turned of caching in the integration-test.
* Explicitly set the commit-interval to a very short period (100ms) in the
  integration-test.

query: 2.0.0 - Defined 2 state-stores (all state in-memory in tests)

* Introduced a second state-store to store the incomming users-table.
* Without the explicit definition of the state-store, it is _not_ possible,
  to reconfigure the integration-test in such a way, taht it does not
  store its state locally on disk.

query: 2.0.0 - Values are serialized as JSON
--
works, still startling, but explainable

* Splitting the command ``table()``, that reads the input-topic and
  materializes it as ``KTable()``, into the two statements ``stream()``,
  that reads the input-topic into a ``KStream``, and ``toTable()``, that
  turns the `KStream` into a ``KTable``, the ``JsonSerde``, that is
  specified via ``Consumed.with(..)``, is only used for the serialization
  and deserialization concerning the ``KTable`` -- not the deserialization
  of the values, that are read from the input-topic.
* Hence, the type-mappings does not have to be specified for the
  ``JsonSerde``, resulting in better understandable code.
* __Note__, that the resulting topology does not differe, because the
  DSL is able to combine the effects of the two statements.

query: 2.0.0 - Values are serialized as JSON
--
works, but is very confusing

* The default-type is specified as a consumption-parameter in the command,
  that reads the input topic into the `KTable` via ``Consumed.with(..)``.
* The resulting code is confusing, because the ``Consumed``-parameter is
  used for both, the consumption of the input topic _and_ the consumption
  of stored values, if read from the state-store.
* Because of this, one might only think of the consumption of the stored
  values from the state-store, when looking at the ``Consumed.with()``-
  statement, and argue, why the type-mappings have to be specified here.

query: 2.0.0 - (GREEN) Values are serialized as JSON
--
works __only__, if a default-type is defined

* The default-type is needed, to deserialized values that are read from the
  state-store.
* Without it, the deserialization fails, because not type-information is
  available.
* The type-information gets lost, when the values are stored in the state-
  store, because the message-headers are _not_ stored along with the value!

query: 2.0.0 - (RED) Formulated expectations for JSON-values

query: 1.0.6 - Added IT, that queries the expected state

query: 1.0.6 - Refactored `TestData.assertExpectedState()`

query: 1.0.6 - Added `QueryApplicationIT`

query: 1.0.6 - Added `QueryStreamProcessorTopologyTest`

query: 1.0.6 - Refined `QueryApplicationConfiguration`
--
the state-store is configurable through a store-suplier

query: 1.0.6 - Refined `QueryStreamProcessor`
--
moved the building of the toplogy into a separate (static) method

query: 1.0.6 - Refined `QueryStreamProcessor`
--
store name is a constant

query: 1.0.6 - Refined `QueryApplicationConfiguration`
--
moved lifecycle-handling of the streams-processor into the config-class

query: 1.0.6 - Refined `QueryApplicationConfiguration`
--
separated the serialization-config into a static method

query: 1.0.6 - Refined `QueryAppilcationConfiguration`
--
moved the creation of the streams-config into the config-class

query: 1.0.6 - Refined `QueryAppilcationConfiguration`
--
separated detection of correct `HostInfo` into a separate ``@Bean``-method

query: 1.0.6 - Refined naming in `QueryApplicationConfiguration`
--
streamlined the naming of attributes and parameters

query: 1.0.6 - Separated config in `Top10ApplicationConfiguration` -- ALIGN

query: 1.0.6 - Separated config in `QueryApplicationConfiguration` -- COPY

query: 1.0.6 - top10: 1.1.1 - Upgraded Java & Kafka

query: 1.0.5 - Updated Spring Boot to `3.2.5`

query: 1.0.4 - changed default-port and exposed all actuator-endpoints

query: 1.0.3 - application.server is derived from the local address

query:1.0.2 - Fixed responses for availability edge-cases

* No invalid redirect, if the host-info ist not available
* 503 Service Temporarily Unavailable, while streams is not ready

query:1.0.1 - Rankings are enriched with user-data

query:1.0.0 - Query rankings by username

top10:1.0.0 - ranks first 10 mostly used words, keyed by user

wordcount:1.0.0 - counts words, keyed by username and word