This may not be the cleanest solution, but there don't seem to be any
way towards this either.
- `UseDestinationValue` has been inherited by default as noted in
https://docs.automapper.org/en/stable/10.0-Upgrade-Guide.html#usedestinationvalue-is-now-inherited-by-default, and its behaviour in this case would be using the nested **managed** realm object for the destination member rather than creating an unmanaged version.
- `MaxDepth` already sets `PreserveReferences` so there's no point of using it.
- `MaxDepth` should probably not be set for all maps, only for those with
cyclic references, to avoid the expensive overhead of `PreserveReferences`, as mentioned in https://docs.automapper.org/en/stable/5.0-Upgrade-Guide.html#circular-references.
That aside, `MaxDepth` should actually only be set to `1` for
`BeatmapSetInfo` mapping, because we don't want AutoMapper to create a
nested instance of `BeatmapSetInfo` in each mapped/detached beatmap, but
for some reason, doing that will cause automapper to not map any beatmap
inside the set and leave it with 0 beatmaps.
While on the other hand, using `MaxDepth(2)` for `BeatmapSetInfo` works,
but creates an unused instance of a `BeatmapSetInfo` inside each mapped
beatmap, which may not be ideal.
For `BeatmapInfo`, it has to be `MaxDepth(2)`, in which the first
`BeatmapInfo` depth would be itself (when detaching a beatmap), and the
second would be nested beatmaps inside the mapped/detached
`BeatmapSetInfo` within the beatmap. (note that when detaching a beatmap
set, the unused instance of `BeatmapSetInfo` within each beatmap of that
beatmap set doesn't also have a list of unused beatmaps as one might expect from the depth specification, it surprisingly has 0 beatmaps)
This causes it to create an unused instance of `BeatmapInfo` in the beatmap set resembling the root mapped/detached beatmap, but that one might be inevitable.
The task not being cleared in the early return path would cause
`pendingRequestTask` to become stuck as a completed task, and
`queryValue()` would not recreate it due to the null check there,
therefore stalling all lookups forevermore until a game restart.
The reason this was happening was an unfortunate oversight in the
migration logic. The code that was attempting to parse the skin settings
as `int` was firing regardless of whether a skin migration from EF to
realm had already occurred. If it had occurred, the skin setting would
contain a GUID rather than an integer, and therefore fail to parse, and
therefore implicitly fallback to a EF skin ID of 0 which would be the
default skin.
Fix by not running the setting migrating logic at all when there are no
EF skins to migrate.
