We had these for some seemingly at random (I assume because
we happened to be using them somewhere).
I needed a bunch more for my next feature, but I thought I would
add all of themnow to avoid having to add more batches in the future.
This is intended to help resolve deadlocks (MBS-11345, MBS-12314) and
performance issues due to lock contention.
It supplants https://github.com/metabrainz/musicbrainz-server/pull/212.
The new implementation is documented in `Data::Role::EntityCache`.
Sometimes users (especially new ones) add an entity as a votable edit
(by checking the relevant checkbox) and are then not notified
that the entity is in risk of removal, since their add edit
means there's a pending edit keeping the entity around.
Unless they have added more data, though, the entity will be removed
soon after the one pending edit passes.
This checks if the creation edit is the only thing keeping the entity
from being otherwise eligible for cleanup. If that's the case,
it then notifies the user with the same banner anyway.
I'm also adding a test to see if the banners show as expected
for artist at least, since AFAICT we were not testing this at all.
Notice that is_empty no longer checks edits directly.
The RemoveEmpty autoremoval script actively checks
for edits anyway, so there should be no risk this change would
cause the wrong things to be removed.
We were doing an eq check on relatable, but track
did not have relatable listed at all in entities.mjs.
Since we do relatable: false for other non-relatable entities,
it seems sensible to also add it to track.
Importing entities.json into a JS file using Flow produces an any-typed
value. Defining a Flow type for this JSON and keeping it up-to-date is
much harder than just defining the ENTITIES structure in JS and letting
Flow create a literal object type for it. We can then generate
entities.json (which is still used by the Perl) from this file using an
added script.
