Instead of relying on file usage, tracking dependency to determine the deletion of files

Problem/Motivation

Follow up #2821423: Dealing with unexpected file deletion due to incorrect file usage, read through all comments, found that no approaches proposed how to resolve the file usages caused potential data loss, eventually.

So I am thinking of forgetting the file usage way temporarily and seeking a new approach.

Let's see how our local file system does to delete a file and its symbolic files.

$ tree .
.
├── bar.txt
└── foo
    └── bar.txt -> ../bar.txt

1 directory, 2 files
$ cat bar.txt 
bar
$ cat foo/bar.txt 
bar
$ rm bar.txt 
$ cat foo/bar.txt 
cat: foo/bar.txt: No such file or directory
$ echo bar > bar.txt
$ cat foo/bar.txt 
bar

Form the above, we can see that deleting the original file does not affect the existence of its symbolic file. -- deleting original, does not mean symbolic were deleted but becoming inaccessible.

Another thing is that even though deleted the original file, once a new one with the same path created, symbolic still works.

Proposed resolution

The rough idea is to only track the original file. More specifically, tracking the dependency/dependencies which brings the original file into the system. Once a dependency is deleted, the original file associated should be deleted, no matter the original is used by anywhere else or not. In general, a dependency is an entity.

For example:

Given:

1. A media entity type: Image (machine name: image), with an image file field (machine name: image).
2. A content-type: Article, with default Title, Body, Image, and Media field references to the media:image using inline entity form.

And

1. Node 1 (nid 1), Image field with an image (fid 1), by using the default image field widget
2. Node 2 (nid 2), Body has an inline image with fid 2, by using ckeditor
3. Node 3 (nid 3), Media field references to a media with mid 1, and an image to this media with fid 3, by using the inline entity form widget

(nid: node ID, fid: file ID, mid: media ID)

1. fid 1 has one dependency, that's nid 1, once nid 1 deleted, fid 1 will be deleted.
2. fid 2 has one dependency too, that's nid 2, once nid 2 is deleted, fid 2 will be deleted
3. fid 3 has two dependencies, they are nid 3 and mid 1, once nid 3 or mid 1 is deleted, fid 3 will be deleted.

Dependencies of files are recorded/tracked once only in general while creating its dependencies.

File usage could be still used to track file usages which should be its main duty, inaccurate stats does not hurt much, but not being used to determine the deletion of a file.

This is just a rough idea. open for discussion.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet