Prepared for the development of version 2.1.0

Released version 2.0.0

Switched from single-node (assign) to multi-instance (subscribe)

* TransferConsumer uses subscribe() instead of assign().
* The subscription happens during the instanciation of TransferConsumer.
* The restorage-process of the state happens in onPartitionsAssigned().
* To be able to reset all data, that belongs to a specific partition
  after a rebalance, in order to avoid state errors because of handling
  events several times, InMemoryTransferRepository must know, which
  partition a transfer belongs to.
* To achieve this, the partitioning algorithm is made known explicitly.
* On each rebalance, a mapping from the partions to the currently assigned
  instances is maintained.
* TransferController uses the explicitly known partitioning algorithm, to
  look up the partion for a requested transfer and decide, if the data is
  available locally.
* If not, it looks up the assigned instance in the maintained mapping and
  redirects the request.

Properties are only accessible via getters

Simplified the thread-execution

Prepared for the development of version 2.0.0

Released version 1.1.0

Ignoring poision pills with illeagal state-changes

Implemented state-change logic

Moved TransferService into package ports

Moved all business logic into TransferService

Automatically rebuild the state after a crash / restart

* Turning of enable.auto.commit and setting auto.offset.reset to earliest
  does the trick in this setup.
* Since no offset-commits are made, all events are re-read on startup.
* The TransferConsumer uses a special instance of TransferService, that
  is initialized with a NoOpMessageService, to replay the restored
  events without generating new events.

Introduced different Events for the creation and the state-changes

TransferConsumer logs the number of polled records only, when positive

TransferController sends a message, instead of calling TransferService

TransferRepository does not need any synchronization

* Only TransferService stores data in the repository
* Since alle instances of Transfer, that are handled by TransferService
  are received through a single topic, no synchronization is needed at
  all in the repository.
* This is, because records, that are received from a topic are guaranteed
  to be processed one after the other.
* The topic simply is the single source for processing requests and a
  KafkaConsumer never handles multiple records in parallel.
* Note: This implementation is not ready to run on multiple threads or
  nodes!

Prepared for development of version 1.1.0

Released version 1.0.0

The build of the docker-image is not triggerd automatically

Added config/assets to build a docker-image

MVP for transfer service