Send the `user_list_incomplete` capability

[gnprice]

In /api/register-queue , the server accepts a client capability user_list_incomplete. See docs: https://zulip.com/api/register-queue#parameter-client_capabilities

We should send that capability. Before merging such a change, we should manually test situations where it would have an effect, and confirm the app behaves properly.

Effects

When the client doesn't send that, the server will make up fake user objects for certain users, consisting of bogus data. This inevitably means bugs whenever that data actually gets used. One live example reported by someone using Zulip in practice is that the bogus data claims the user has role "Member", even if in reality they're a guest: #issues > Guest can see other guests with title 'Unknown user' @ 💬

That particular symptom isn't as easy to reproduce in the mobile app, because we don't have an analogue of web's right sidebar. But I believe it would reproduce like so:

• Have user A, a guest, send some messages in channel C.
• Unsubscribe user A from channel C.
• Have user B, also a guest, join channel C, with no other channels and no DMs exchanged with user A.
• As user B, look at the messages user A sent. Tap their name or avatar to see their profile page.
• Expected: the profile page shows an error, saying the user couldn't be found.
• Predicted symptom: the profile page untruthfully says A is a member, just like the bug reported in web.

There's a milder symptom that appears before that:

• Same setup as above, up to looking at the messages user A sent.
• Expected: the sender is shown as "(unknown user)".
• Predicted symptom: the sender is shown as "Unknown user".

Implementation

The code change to start sending the capability is easy. The main work for any PR for this issue will be in verifying that it behaves correctly.

In particular, this means setting up a situation where the capability causes a difference in behavior; to do that, try the repro recipe above. Then explore every possible way in the app to interact with the affected user, and confirm that with the capability set (and the resulting behavior from the server), the app behaves appropriately.