Execute the user_settings object transition

[timabbott]

In #19404, we just added the feature level 89 migration to change how we encode user settings in the Zulip API to use a user_settings object.

The API documentation should explain the transition clearly. Here's the recommended strategy:

• Clients can immediately switch from processing the update_display_settings and update_global_notifications event types and process the user_settings event type instead.
• Clients may then want to refactor how they store user settings to have a common module/object.
  The web app did this migration in zulip/zulip@998d710.
• Clients can then pass the user_settings_object client capability to all Zulip server versions (older servers will ignore it). If the server returns a user_settings object in the register response, the client should use that to initialize its user_settings object using the user_settings portion of the response; otherwise it should use the user personal settings flags that appear in the top-level response.

[neiljp]

I just came across this in looking at #1163 (#1136). In that PR there is no migration, just an addition of user_settings for initial fetch and events for the new setting, which appears to be only in the user_settings object and absent in the top-level response - without using the capability option.

Is the idea that newer settings will be in user_settings by default, and using the capability will do a migration/merge of settings automatically into one dict/object for servers understanding that capability?

Support of multiple (ie. older) server versions is not completely clear from the current docs. The notes above seem to assume that the migration can occur immediately, perhaps neglecting support of older servers? (I'm not sure how switching processing different events could span server versions, for example)

To clarify my thoughts on how to proceed while supporting old servers:

• request all 3 events (ie. add user_settings for new features)
• request all 3 types in initial fetch (ie. add user_settings for new features)
• handle each set individually initially (ie. look for new features in user_settings)
• potentially merge all user settings into one location
• add the client capability and migrate towards a situation where source data can be detected in original and new locations
• eventually drop old fetch/event events and don't look in old locations for data