`viur-blob-locks` entities are just using `id_or_name`

[sveneberth]

I need to test and recheck this, but as far as I see there is a problem with viur-blob-locks.

viur-blob-locks prevents files (whether weak or not) from being deleted, even if the FileSkel has already been deleted.

When saving the skeleton, all the dlkeys used are collected with the help of getReferencedBlobs and saved in a viur-block-locks entity. However, this only uses the id_or_name of the skeleton key.

viur-core/src/viur/core/skeleton.py

Lines 1144 to 1164 in 3a681bc

	if not is_add and (old_blob_lock_obj := db.Get(db.Key("viur-blob-locks", db_key.id_or_name))):
	removed_blobs = set(old_blob_lock_obj.get("active_blob_references", [])) - blob_list
	old_blob_lock_obj["active_blob_references"] = list(blob_list)
	if old_blob_lock_obj["old_blob_references"] is None:
	old_blob_lock_obj["old_blob_references"] = list(removed_blobs)
	else:
	old_blob_refs = set(old_blob_lock_obj["old_blob_references"])
	old_blob_refs.update(removed_blobs) # Add removed blobs
	old_blob_refs -= blob_list # Remove active blobs
	old_blob_lock_obj["old_blob_references"] = list(old_blob_refs)
	old_blob_lock_obj["has_old_blob_references"] = bool(old_blob_lock_obj["old_blob_references"])
	old_blob_lock_obj["is_stale"] = False
	db.Put(old_blob_lock_obj)
	else: # We need to create a new blob-lock-object
	blob_lock_obj = db.Entity(db.Key("viur-blob-locks", db_obj.key.id_or_name))
	blob_lock_obj["active_blob_references"] = list(blob_list)
	blob_lock_obj["old_blob_references"] = []
	blob_lock_obj["has_old_blob_references"] = False
	blob_lock_obj["is_stale"] = False
	db.Put(blob_lock_obj)

Which means that if two skeletons in different kinds have the same id_or_name, they will always overwrite each other's viur-block-locks entity.

In ViUR2 the complete key (including kindname) was used, so there were no conflicts: https://github.com/viur-framework/server/blob/e53c744834103a467a5f51b6b29db7aa531a6096/skeleton.py#L708

---

I think the probability that the same id is used twice with the randomly used ids is low. Especially if projects only have a few entities (< 1000). But it is not impossible. We should therefore change this implementation asap and use ancestors, for example.

---

The problem is to some way related to #1211. However, since I assume that in this case it is really caused by the error that is fixed in #1213, I would look at this separately.