JavaScript component filenames become invalid after hash salt change/rotation

Overview

When the compiled JavaScript and CSS code for code components get written to a file, the filename is calculated using \Drupal\Component\Utility\Crypt::hmacBase64 with Settings::getHashSalt() as the key. Whenever we access the files, the filename is re-calculated on-the-fly. Due to relying on the value of Settings::getHashSalt(), the filenames are not stable.

1. Rotating the hash salt is a security best practice;
2. Cloning database and files between different environments can happen, and different environments will have different hash salt values.

These scenarios cause the Astro Islands to point at non-existing files.

Proposed resolution

Change the way the filename is calculated or store the calculated filename on the JavaScriptComponent entity instead of calculating it on-demand. — use the config entity's uuid, which is also used for config management/syncing/importing: duplicate UUIDs are refused, and will result in an error like An entity with this UUID already exists but the machine name does not match.

That achieves the same end result, without the per-environment dependency of the hash salt.

More context:

1. The code for calculating the filenames was added in commit 9d295 in #3498889: ComponentSource plugin for code components.
2. @longwave suggested if we could "use a more user friendly filename and rely on the Drupal cache busting query string to handle invalidation" while working on #3499933: Storage for CSS shared across in-browser code components (and other use cases in the future), and Wim agreed as a future improvement. Maybe it's time to make that happen?