Fix settings overlay components not invalidating presence on filter change

[frenzibyte]

Fixes #17929, again

Prior to #17823, filtering would update the Alpha value of the settings overlay components (sections & items), which would invalidate Presence along the way, to note to parenting flow containers that re-performing layout is necessary.

But now on master, filtering would instead update the IsPresent state directly without an invalidation, resulting in the settings panels not laying out properly and get into a completely weird state.

Added test coverage by filtering after load, as that's when the settings overlay starts relying on invalidation to reflow the sections.

Note that this also reverts #17931 as it's still no longer necessary, but I will suggest quadruple-checking the overlay in all ways possible to ensure nothing has regressed yet again. I've tested enough and can't find anything broken now.

[bdach]

requesting changes due to actual test failures and doubts about direction

[bdach]

I don't know about this. In an ideal world, this sort of thing should be handled by framework. There are several other IsPresent overrides in the game alone even and as far as I understand every single one is susceptible to this same bug of invalidations not firing on custom presence criteria changing. And not every one of those will be so easily fixable as this one (the ones that check Scheduler.HasPendingTasks certainly aren't going to be...)

[frenzibyte]

For sure, but I'm not really sure how it should be approached framework-side. If anything, we probably don't want to allow IsPresent to be overridable in the first place, to avoid this weirdness happening.

If I were to guess of a proper fix, it might be to have something similar to the ShouldBeAlive and IsAlive flow (in which the former is an overridable property, while the latter is updated internally to the state of the former).

But for now, every override of IsPresent must invalidate Presence, and I'm unsure how that should be achieved for all overrides, so I sticked into fixing SettingsOverlay which is the most important here.

[peppy]

Is this the kind of case we want to use AddLayout instead?

[bdach]

AddLayout solves the inverse problem doesn't it? LayoutMember is for when you want to recompute something when an invalidation happens. But the issue here is that due to IsPresent being a computed read-only property, framework can't know when it changes to fire off an invalidation without adding some flow that would check whether the value changed between consecutive reads.

[peppy]

Ah yep, that makes sense.

I guess this is okay for now?

the blocker is resolved, i suppose