Improve efficiency of tag population

[peppy]

• No longer holds realm write transaction open while performing sqlite lookups.
• No longer attempts a write transaction when it will be a noop.

I'll admit that this is maybe working around the actual realm write part being slow, but as I can't profile the issue locally, the sluggishness may actually be in sqlite for those users affected (since it's only been reported for tag population and not difficulty calculation?).

Regardless, this should fix the issue this iteration.

I also adjusted the user messaging to let them know why tag population is happening, since we've had some questions as to why it's running in the first place (it only happens once a month, so that's understandable).

• Depends on Add method for silently dismissing progress notifications without completion #37227.
• Closes Song Select Performance very noticably worse than osu!stable #34699.
• Closes populating missing user tags starts again after updates even though completed tags persist across normal restarts #37210.

Note that #36128 also exists and has valid improvements which can be addressed separately. This is intended to be something we can act on immediately.

[cyperdark]

hello i have this PR #36128 which have larger scope but improves tags population and other BackgroundDataStoreProcessor processes as well

but currently it lacks benchmark project and unfortunately i have not much knowledge of C# nor of codebase to make it, so as was suggested im waiting on someone from osu dev team to make it instead: #36128 (comment)

[peppy]

See my note in the OP. Your effort is orthogonal to what I'm doing here. This change doesn't require benchmarking or much review attention because it's doing very obvious things that we're used to.

[cyperdark]

oh shit i might've had old page open and didnt see note, sorry

[peppy]

@cyperdark Once this is merged, if you have the energy please rebase your PR. Also consider splitting it out into multiple pieces. For instance, the reusable sqlite connection should be its own PR to make reviewing and merging easier. I'm more inclined to consider that one before the batching one (because as we've seen, the batch commits still showed overheads in your testing).

[bdach]

even in a naive one-shot my-machine manual stopwatch check against master, this is an order of magnitude faster on a large database I test with than master. so we can probably start here and see whether any of the remaining tweaks are even really necessary for most.

@peppy please double-check that I resolved the conflicts with master in the way you would expect. squash merges are not really that compatible with PR chains.