Avoid entity saves in lingotek_entity_insert(), as it can be highly problematic

lingotek_entity_update() will have the same problem - resaving an entity during it own save events is not robust.

I think some of the logic should move to a presave - i.e the calculation of of the hash. And then you just need to compare the original value with the new value.

Actually this is a critical bug for this module as it is likely to not make it inter-operable with many modules. Update hooks firing before insert hooks is very surprising :)

I think this patch should fail because \Drupal\lingotek\LingotekContentTranslationService::hasEntityChanged is not quite right yet - it needs to account for the presave change.

Good that failed...

The other option here is to try and not save the hash on the content entity. Given the changes content_moderation might bring to core that might be a desirable route. We could just use $entity->original and $entity during hook_entity_insert and hook_entity_update to work out if there is anything to do. That should work in those cases - I'm not 100% certain about the other cases where the hash is used.

Whoops.

+++ b/lingotek.module
@@ -33,6 +33,32 @@ function lingotek_toolbar() {
+  // Make sure lingotek_entity_presave() comes last.
+  switch ($hook) {
+    // Move our hook_entity_type_alter() implementation to the end of the list.
+    case 'entity_presave':
+      $group = $implementations['lingotek'];
+      unset($implementations['lingotek']);
+      $implementations['lingotek'] = $group;
+      break;
+  }

This is not great but if we're going to save the hash to content entity probably the best option because it won't result in double saves.