Add user groups to store and API binding

[gnprice]

Fixes #662, toward #233 user-group @-mentions.

[chrisbobbe]

Thanks! Just one comment below, otherwise LGTM please merge at will.

I wonder if we want to sometimes do a smoke test with the earliest supported server version (7.0 now) to make sure we're not accidentally breaking support for some servers.

[chrisbobbe]

The doc says "New in Zulip 10.0 (feature level 290)"; I think we want to make this optional?

[gnprice]

Oh good catch, thanks. And I guess we can default it to false — I think before that feature level, there just was no concept of a deactivated group, so all groups were effectively active.

[chrisbobbe]

before that feature level, there just was no concept of a deactivated group

Hmm, realm_user_groups in register-queue says:

Changes: Prior to Zulip 10.0 (feature level 294), deactivated groups were included for all the clients.

I'm not sure whether or not that's consistent with that.

[gnprice]

Yeah, that caused me to have to reread a couple of times. But I think the story is:

• Starting in 290, there was such a thing as a deactivated group.
• Then starting in 294, deactivated groups were kept out of the list by default.

See also the 290 and 294 entries in the changelog https://zulip.com/api/changelog . In particular 290 includes:

• POST /user_groups/{user_group_id}/deactivate: Added new API endpoint to deactivate a user group.
• POST /register, GET /user_groups: Added deactivated field in the user group objects to identify deactivated user groups.

[chrisbobbe]

Cool. This makes sense then:

And I guess we can default it to false

[gnprice]

I wonder if we want to sometimes do a smoke test with the earliest supported server version (7.0 now) to make sure we're not accidentally breaking support for some servers.

Hmm, with a live server, then?

Yeah, in principle that would probably be a good thing to do. I think that's been a rare class of bug for us to have, though, and it's an expensive type of test to set up and maintain (and to run), so I don't expect it to be a priority any time soon.

Effectively we've been relying on Zulip's high-quality API docs, including its meticulous change notices; and on both author and reviewer reading those API docs, like you just demonstrated 🙂

[gnprice]

Huh, infra failure in CI:

Downloading Linux x64 Dart SDK from Flutter engine 36b77984e2ee2b734a5ec59fe1193da311888f01...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   255  100   255    0     0   411[8](https://github.com/zulip/zulip-flutter/actions/runs/16157122950/job/45601779716?pr=1688#step:6:9)      0 --:--:-- --:--:-- --:--:--  4180
[/home/runner/flutter/bin/cache/dart-sdk-linux-x64.zip]
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of /home/runner/flutter/bin/cache/dart-sdk-linux-x64.zip or
        /home/runner/flutter/bin/cache/dart-sdk-linux-x64.zip.zip, and cannot find /home/runner/flutter/bin/cache/dart-sdk-linux-x64.zip.ZIP, period.

It appears that the downloaded file is corrupt; please try again.
If this problem persists, please report the problem at:
  https://github.com/flutter/flutter/issues/new?template=01_activation.yml

Rerunning.

[gnprice]

Retried a couple of times; same error on all three tries so far.

[gnprice]

… Well huh. That commit is Flutter's origin/main… but not its origin/master:

$ git log --oneline --graph --boundary 36b77984e2ee2b734a5ec59fe1193da311888f01...origin/master
* 36b77984e (origin/main) fix minor spelling mistake in roadmap (#167888)
| * 43312d1cd (origin/master, origin/HEAD) Roll Fuchsia Linux SDK from AinHuT0vgOelA1g7_... to 0-xqmXWc4cXzw3tfe... (#171823)
|/  
o e80b19126 Marks Linux_android_emu android_display_cutout to be unflaky (#171140)

That shouldn't happen. And that probably explains why we're failing to fetch an engine artifact from there.

[gnprice]

OK, worked around that infra issue in #1690. Now CI is failing only here:

================================================================
Running flutter_version...
fatal: ambiguous argument 'origin/main..d35bde5363d5e25b71d69a81e8c93b0ee3272609': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
================================================================

I'll fix that too; but it's unrelated to this PR, so I'll go ahead and merge.