Mute muted users

[gnprice]

This Zulip feature: https://zulip.com/help/mute-a-user .

This issue only covers respecting the user's existing choice to mute (or unmute) a given user. Offering UI for changing that choice is a feature we don't have in zulip-mobile (zulip/zulip-mobile#4655), and will be a separate issue.

That help-center doc has a handy (and long) list of places in the UI that should respond to user muting. where the user's name and avatar are hidden. One other such place is:

• on a user profile screen (of not necessarily a muted user), in a custom profile field with type user, when the muted user is among the users listed there.

  (I happened to notice this when reviewing profile: Implement profile screen for users #287 and comparing a profile screen between the PR and zulip-mobile, which does mute users in this spot.)

Because the list of places that should be affected is so long, we should find ways to encapsulate many of those to go through a much smaller number of distinct places in the source code; otherwise it'll be very easy to miss some, and to forget this feature when adding new pieces of UI that happen to show a user's name or avatar.

• One point of comparison for that encapsulation is the UserItem component in zulip-mobile. It's used in 8 other components; and expanding the call tree through the generic UserList and UserPickerCard, it's ultimately used in 11 different places in the UI.

  Similarly UserAvatarWithPresence, which is used in UserItem and used directly by several other pieces of UI.

• Another job which is probably convenient to handle as part of the same encapsulated piece of code is to deal with the case where a user is unknown, i.e. not in our data structures (which will become quite normal with Add support for denying guest users access to all other users in the organization zulip#10970 ). We've been defaulting the avatar to transparent and the name to "(unknown user)". It's already awkward that that logic is duplicated in each piece of UI that needs it — makes it easy for different places to diverge accidentally, as in profile: Implement profile screen for users #287 (comment) — and it'll get more so when the "(unknown user)" part needs to gain complexity for i18n. So we need to encapsulate that job too, independently of the need for muting users; and they probably belong in the same abstraction.