Content changes tracking on our own instead of continuous job mechanism

1. +++ b/tmgmt_extension_suit.module
   @@ -204,28 +179,64 @@ function _tmgmt_extension_suit_get_job_item_hash(JobItemInterface $job_item) {
   +          if ($old_hash != $hash) {
   

   Please use strict comparison

2. +++ b/tmgmt_extension_suit.module
   @@ -204,28 +179,64 @@ function _tmgmt_extension_suit_get_job_item_hash(JobItemInterface $job_item) {
   +        if (!empty($is_reopen_needed)) {
   

   is_reopen_needed is boolean. Why do we need "empty" function here?

+++ b/tmgmt_extension_suit.module
@@ -204,28 +134,60 @@ function _tmgmt_extension_suit_get_job_item_hash(JobItemInterface $job_item) {
+    $select->condition('tji.state', [JobItemInterface::STATE_ACTIVE, JobItemInterface::STATE_REVIEW, JobItemInterface::STATE_ACCEPTED], 'IN');

Why do we need this filter here? Should we ignore the "INACTIVE" state?

+++ b/src/Plugin/QueueWorker/JobDownload.php
index e69de29..da1fe26 100644
--- a/src/Plugin/QueueWorker/JobUpload.php

+++ b/tmgmt_extension_suit.module
@@ -204,28 +134,68 @@ function _tmgmt_extension_suit_get_job_item_hash(JobItemInterface $job_item) {
+            // We don't use JobItem::setState() method because it can invoke
+            // JobItem::save() by itself depends on condition "if current state
+            // != new state". We're just setting up state manually and call

We don't use JobItem::setState() because it doesn't always call JobItem::save(), and so the behaviour might be inconsistent.