While a mod-created replay did flag itself as performed by a bot, the extension method converting it into a Score did not copy all the generated properties.
As noted, it might be preferable for ModCreatedUser to inherit APIUser and forward it as-is to the Score instance.
Related to PR #24675
The mod generally will only be present on scores imported from stable.
As such, it's probably ok to mark it as such.
The primary reason for this change is to address #24436 (Score V2 being
visible on beatmap overlay leaderboard mod selector).
There is one possibly-unintended consequence of this change, namely that
the results screen uses `UserPlayable` to determine as to whether
animations should be played back, with the intention of turning off the
animation playback for autoplay scores specifically. Therefore, turning
off this flag will mean that the results screen animations will not play
out for Score V2 scores - but I tend to consider this as either largely
unimportant, or something that should be fixed in some other way
(possibly by checking against the autoplay mod directly).
Other usages of `UserPlayable` are either innocuous, or straight-up good
safeties going forward in the context of Score V2 (guards against
selection in mod select overlays, against score submission with
the mod).
This API endpoint is intended for usage with the entire `solo_scores`
machinery and ID schema, rather than the legacy `*_scores_high` ID
schema. It also supports automagically falling back to downloading
legacy replays if a stable-imported score is requested for download
(internally this happens via `legacy_score_id` in the `data` json).
This change will allow replays to be downloaded, but it will still not
yield 100% correct behaviour, as there is further work to be done in
that respect. The download tracker is expecting score hashes to arrive
from web to verify the integrity of the incoming download, but the API
does not expose such a facility right now; we will have to decide as to
whether we want to add one web-side, or whether we want to disable the
checking client-side.
The fallback to "any of the added sets" needs to be applied after
they've all been added, rather than with every added one. Otherwise, in
flows that expect a particular difficulty to be selected in the end
(such as exiting from editor) would end up switching away from the
edited beatmap.
Sentry documentation suggests this should be on for a client-facing app.
We haven't run into issues without it until now, but might as well set it correctly?