Add deduplication logic for kafka sink in case of spark task retries

Bắt đầu bằng cách xem xét DeduplicateKafkaSinkTransformer hiện có và số lần thử của tác vụ Spark có sẵn trong quá trình retries. Đánh giá một Kafka ProducerInterceptor xử lý retries giữa các executor và duy trì tra cứu trong bộ nhớ cho các retries trên cùng executor; được coi là hoàn thành khi các bản sao trùng lặp bị loại bỏ hoặc được chuyển hướng đến một trash topic theo các giả định đã nêu.

Problem description
Spark does not provide an exactly-once behaviour for the Kafka sink, but only at-least-once, and will probably never do so (https://github.com/apache/spark/pull/25618). Under certain assumptions (no concurrent producers, only 1 destination topic, not too big micro-batches, messages don't change between retries), idempotency can still be achieved. See #177.

The DeduplicateKafkaSinkTransformer only addresses retries on an application level. However, retries (and therefore duplicates) may happen on lower levels as well, namely:

• Retry of a DataWritingSparkTask (the Spark task that will invoke the KafkaProducer)
• Internal retry of the KafkaProducer (when encountering a RetriableException, e.g. server disconnected)
  Duplicates due to an internal retry of the KafkaProducer can be prevented by setting acks=all and enable.idempotence on the kafka writer. However, this does not take into account retries of the DataWritingSparkTask which invokes the KafkaProducer. For example, if there is an intermittent TopicAuthorizationException, the KafkaProducer will fail and not retry, but the DataWritingSparkTask will retry nevertheless. In such a case, duplications are still possible. Another example is executor failure due to exceeding memory limits. If an executor exceeds memory limits during the DataWritingSparkTask, it will be terminated and another executor will retry the task, which may again lead to duplicates on the destination topic.
  One solution is to switch off spark task retries, but obviously, this causes other problems.

Solution
It might be possible to implement a org.apache.kafka.clients.producer.ProducerInterceptor which would deduplicate retries messages in a similar way as the DeduplicateKafkaSinkTransformer. This would capture duplicates in a scenario where the retry happens on a different executor than the original executor (memory exceeded scenario). In addition, the interceptor should keep a lookup set in memory to capture duplicates that occurred due to retries on the same executor
(TopicAuthorizationException scenario).
A reattempt could be recognized through the attempt nr of the Spark task.
If messages cannot be dropped through the ProducerInterceptor, they could at least be redirected to a trash-topic