Fix temporary sync errors if there's weird settings stored in account data

[turt2live]

When #8798 made its changes to the SettingsStore it subtly changed how getLevelOrder actually worked. The previous behaviour was a simple if (ordered) { return orderedLevels; } else { return DEFAULTS; } but the new behaviour added a check for if there was only ever one supported level, in which case it'd return that single level instead of the defaults. This is the correct behaviour and should in fact be enforced as it is, however it had a weird knock-on effect.

Earlier, I noticed my sync loop was a bit slow. This was found in the console:

rageshake.ts:73 Caught /sync error Error: Level "account" for setting "useCompactLayout" is not prioritized
    at SettingsStore_SettingsStore.getValueAt (SettingsStore.ts:363:36)
    at localizedCallback (SettingsStore.ts:178:51)
    at WatchManager_WatchManager.notifyUpdate (WatchManager.ts:72:13)
    at MatrixClient.<anonymous> (AccountSettingsHandler.ts:69:31)
    at MatrixClient.emit (events.js:158:1)
    at MatrixClient.emit (typed-event-emitter.ts:61:22)
    at sync.ts:1170:28
    at Array.forEach (<anonymous>)
    at SyncApi.processSyncResponse (sync.ts:1159:20)
    at SyncApi.doSync (sync.ts:920:24)

The error only shows up if getLevelOrder returns levels which aren't supported by the level provided to getLevelAt (called implicitly through a WatchManager update from the AccountSettingsHandler when it detects a change in account data). For the particular setting involved, the useCompactLayout setting has never supported the account level so it's surprising to see it come up in that context - I probably have it lingering in my account data from a previous test or something.

So, when the account data comes through and triggers an internal notification to the watch manager, it tries to read the value of the setting from a wrapped callback in order to provide more information to the downstream watching code. This read fails because of the weird setting name in an unexpected location. Previously, it wouldn't have been an issue because it was assumed that the default levels would cover the setting's off-spec behaviour, but with the change to returning the single level in the case of single-level-supported settings it ended up accidentally breaking settings like this which only listen at the device level.

---

Ultimately, I feel this is a super rare case that doesn't need a regression test. We should have more tests on the settings store generally, though I also would like to Ctrl A + Delete it from the project (replacing it with a new one with proper types, a la #5669 )

---

Here's what your changelog entry will look like:

🐛 Bug Fixes

• Fix temporary sync errors if there's weird settings stored in account data (#8857).

[SimonBrandner]

Otherwise LGTM