Ensure realm subscriptions always fire initial callback with null ChangeSet

[peppy]

We expect this to be the case, but it turns out that it may be coalesced:

Notifications are delivered via the standard event loop, and so can't
be delivered while the event loop is blocked by other activity. When
notifications can't be delivered instantly, multiple notifications may
be coalesced into a single notification. This can include the
notification with the initial collection.

Rather than struggle with handling this locally every time, let's fix the callback at our end to ensure we receive the initial null case.

I've raised concern for the API being a bit silly with realm (realm/realm-dotnet#3641).

[peppy]

Hold up this isn't correct.

[smoogipoo]

If sender contains the items after the modifications are applied, then shouldn't we not send the non-null callback if initial == true?

To further expound, when you send (sender, null), the callsite will use those items to populate the initial list:

osu/osu.Game/Screens/Select/BeatmapCarousel.cs

Lines 279 to 282 in c100d1a

	if (changes == null)
	{
	realmBeatmapSets.Clear();
	realmBeatmapSets.AddRange(sender.Select(r => r.ID));

But then we send the (sender, changes) callback which could be used to e.g. delete from that "initial list" from above:

osu/osu.Game/Screens/Select/BeatmapCarousel.cs

Lines 290 to 294 in c100d1a

	foreach (int i in changes.DeletedIndices.OrderDescending())
	{
	setsRequiringRemoval.Add(realmBeatmapSets[i]);
	realmBeatmapSets.RemoveAt(i);
	}

But the deleted indices are actually irrelevant here because we did not previously have an initial list.

It depends on what sender truly is in the case when the changes have been coalesced - is it the initial list before any modifications, or is it the list after all coalesced modifications.

[peppy]

Yeah just noticed this very thing in further testing. Fixed in ee9e329.

[smoogipoo]

Makes sense to me