Centralizes ask timeout handling. Inner ask timeouts are computed given the outer ones. Also removes useless configuration files and fix related test configuration.

Currently, coordinators are created once, together with the cluster initialization, while metrics actors are created following cluster member lifecycle callback.
Coordinators must be created following cluster events as well, and, since they are not unique anymore, they must have convenient name that make them easily discoverable among the cluster.

It would be good to mention why is Lithium chosen as the akka split brain resolver and maybe explain it's configuration and behavior in the cluster or architecture documentation.
How well tested is it? Can it be swapped out with other SBRs? What's it's configuration and how to override (if it makes sense for the NSDb use case).

When a write batch is completed, it must be replicated to another node in order to guarantee fault tolerance.
This operation must be executed in background

The goal is to widen support for complex types on structured schemas (e.g. logical types).

The connector should be able to handle both raw and processed data when the schema is structured.

Along this, we should move nullable data discovery to previous steps of the SinkRecord processing logic.

Due to a limitation of the KCQL library, it is not possible to set a constant number for the value in the kafka connector sink.
Value must often be a constant (e.g. 1 in case the event represent the measure int itself).

In order to close this gap in a effective manner (without contributing to the external library), a new parameter can be added to the configuration and it would represent the default value to be used in case it is not provided in the kcql expression

It could be a good improvement to use two different actors for read and write operations.
This guarantees that a long term query does not affect write throughput.

In the web ui, a dummy page (probably created by a react template) is still present. Could be a little but appreciated enhancement to remove it.

Currently, metadata infrastructure is designed to support only one location for a metric shard.
In order to implement replication, this behaviour must be enriched in the following way:

• When write coordinator asks for a write location to store a record in, the metadata coordinator must return a set of locations, according to the replication factor.
• Similarly, read coordinator, when it asks for metric locations, will get a set of location for a single shard and it must choose which locations to spread messages among.

The algorithm responsible for the location choice (either for write or for read purposes) will be analysed in another issue. In this issue scope, this can be at random.

CommitLog functionality has to be revised to be compliant with data replica and cluster level consistency.