Implement group-based permission checks

[gnprice]

In the Zulip API, we've recently introduced a new group-based permission system, where a realm's admins can define arbitrary user groups to use for permissions. This is more flexible than the old roles-based system, which has a fixed handful of roles like "admin", "moderator", or "member".

Mostly this is a matter for the server, and for admin settings UIs, and we generally implement very little of an admin settings UI in the Zulip mobile apps (leaving users to go to the web/desktop app to handle those tasks). But in some places a client also needs to check if the user has a given permission, in order to give them a good experience in the case where they don't. For example, #791.

So we need to implement permission checks, and we should do so with the new API. In particular, new permission settings in Zulip (like #791) are being expressed only in the new system, so it's the only way to properly handle those.

This issue is for implementing the infrastructure of that system, so that we can easily add new permissions checks that use it when we need them. That means:

• First, as a prerequisite, implement Store user groups #662.

• Then implement a method for "user A is transitively in group X". The desired semantics are transitive: if user A is in group Z, which is in group Y, which is in group X, then A is transitively in X and Y as well as Z.

  API reference for this: https://zulip.com/api/group-setting-values
  See also the web implementation, at is_user_in_group in user_groups.ts.

• Implement some particular setting that uses the system, so we can demonstrate end-to-end that the implementation works.

  I think the one current candidate for this is direct_message_permission_group and direct_message_initiator_group (for Support new settings for restricting direct messages #791).
  The server also has can_mention_group (this feature), which we'd use as part of autocomplete: Support user-group @-mentions #233.
  I'd thought I'd seen mention of stream_post_policy (for Hide compose box based on stream posting policy #674) getting turned into a group-based setting; but I don't see that in the server API.
  By the time you read this, there may be more: see https://zulip.com/api/changelog after feature level 270 (the latest as I write this).

[chrisbobbe]

• Implement some particular setting that uses the system, so we can demonstrate end-to-end that the implementation works.

The edit-topic permission is another candidate for this, used for

• Check user-groups permissions before offering "Mark as resolved" #1159.