As a product owner I want that message timestamping is refactored, so that it is more robust

[raits]

The fix created in XRDDEV-145 slightly increases the possibility that, when using batch timestamping, some messages are timestamped twice. This is inherently due to the implementation that can start a new batch timestamping process before the previous one is finished.

LogManager#TimeStamperJob schedules timestamping periodically

TaskQueue handles the time stamping requests, but the actual time stamping is handled asynchronously by Timestamper and temporary TimeStamperWorker, making it possible that several time stamping workers are running at the same time.

The results are written to the database only after the timestamping succeeds. Therefore, if a new job is started while the previous one is running, the new job will see the same records.

The JIRA issue this was created from can be found here: https://nordic-institute.atlassian.net/browse/XRDDEV-174

Acceptance criteria:

• A new timestamping process should not start until the results of the previous batch are committed (Alternatively, concurrent timestamping processes should not process the same records).
• The timestamping should adapt to load so that it does not fall behind (see https://nordic-institute.atlassian.net/browse/XRDDEV-145 for additional details).