ProducerRecord for retry tasks could be generated with timestamp=0

[ocadaruma]

• When we consume non-DecatonTaskRequest topic with TaskExtractor, TaskMetadata#timestampMillis could be set to 0 (i.e. long's default value) if we don't set it explicitly.
• Retry tasks inherits original task's metadata https://github.com/line/decaton/blob/v1.1.0/processor/src/main/java/com/linecorp/decaton/processor/runtime/internal/DecatonTaskRetryQueueingProcessor.java#L57
• DecatonTaskProducer sets ProducerRecord#timestamp from TaskMetadata
  • https://github.com/line/decaton/blob/v1.1.0/client/src/main/java/com/linecorp/decaton/client/internal/DecatonTaskProducer.java#L69
• Thus, retry tasks will be produced with ProducerRecord#timestamp=0

This could cause the messages to be deleted on the broker side unexpectedly earlier, since retention-based log deletion is happened based on record's timestamp. (https://kafka.apache.org/documentation/#impl_deletes)