Prepare our file handling logic to residue left behind from previous installations

Problem/Motivation

This is a follow-up of ACMS-4080 MR!71, in which Asset::getLocalThumbnailUri() (source) has introduced an implementation flaw: currently it uses two different utilities (\Drupal\Core\File\FileSystem and \Drupal\file\FileRepository) for the same purpose of handling locally stored images. Apparently, in most cases, it works, but at least one situation has already been found when do not.

After the reinstallation of the module, during the creation of a new media item (usually by inserting via the Media Library modal window), if the {webroot}/sites/default/files/acquia_dam_thumbnails directory already contains a thumbnail image in its {asset_id}/ subfolder with the {version_id}.png filename (for example, as a residue of an earlier installation), then the getLocalThumbnailUri() fails when trying to clear up the space before creation (around lines 555-560):

1. First, the scanDirectory() of FileSystem reports that there are files, which is true.
2. Then, in response, the FileRepository is ordered to delete those files.
3. However, this is impossible: there are no managed file entities that exist in the DB anymore (as we're after a reinstallation).

Steps to reproduce

1. Install and configure the module as usual
2. Manually create a {webroot}/sites/default/files/acquia_dam_thumbnails/{asset_id}/{version_id}.png file with a given DAM asset existing in Widen.
3. Browse that DAM asset and try to insert into either a reference field or a WYSIWYG editor.
   • Actual: nothing happens on the GUI, error appears in the console
   • Expected: media item should be created properly.

Proposed resolution

Implement a more sophisticated freeing-up process something similar:

1. First, ask the low-level FileSystem utility whether the given URI path is vacant or not.
2. If yes, then no problemo, go ahead!
3. If not, then ask the more advanced FileRepository utility whether if it's aware of any managed file entity?
4. If there's a managed file entity, then delete it properly on the level of Entity API. This will cause two things:
   • The good: we got our desired URI freed up.
   • The bad: any old media entity referencing this managed file will lose its thumbnail, which is technically possible, core's Media API is prepared to handle such a situation.
5. If FileRepository says there's no managed file known about, then tell FileSystem to feel free and go ahead for delete what it finds in the directory.
6. Now we have the green light and can continue with storing our fresh data there.

Remaining tasks

More feedback would be appreciated before hitting the lines of code to change anything.